Converting a package to singlespec: two questions

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Converting a package to singlespec: two questions

Lee Duncan
Hello:

I am converting a package, targetcli-fb, to singlespec. I have already
converted the packages it relies on.

I have a couple of problems:

1. The package is called "targetcli-fb". Since this does not follow the
"pyton-PACKAGENAME" convention, what should the python3 version of the
package be called? Perhaps something like targetcli-fb-python3? or
"python3-targetcli-fb"? I don't like either.

2. This package installs some stuff that should be invariant with
respect to python version, such as the directory /etc/target, and the
systemd service unit file /usr/lib/systemd/system/targetcli.service.

I know I can use update-alternatives to handle the man pages and
binaries (scripts) in a singlespec package, but I do not think that
approach will work for a data directory nor for a systemd unit file.

Ideally, as I think about it, I do not want users to be able to install
both the python2 and the python3 version of this package at the same
time. Does it make sense to do that with a singlespec package? If so,
how do I specify this in the SPEC file?

I'm tempted to just create a separate package, make it singlespec and
python3 only. But that doesn't seem much better.
--
Lee Duncan
SUSE Labs
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Converting a package to singlespec: two questions

John Paul Adrian Glaubitz
On 12/11/2017 01:36 AM, Lee Duncan wrote:
> 1. The package is called "targetcli-fb". Since this does not follow the
> "pyton-PACKAGENAME" convention, what should the python3 version of the
> package be called? Perhaps something like targetcli-fb-python3? or
> "python3-targetcli-fb"? I don't like either.

Please use the common python-$PACKAGE naming scheme, anything else would
just be confusing. Users expect Python packages in openSUSE to follow
the common naming scheme. If you use something else, your package will
be harder to find.

I also don't know whether python-rpm-macros will actually work with
packages not following the python-/python3- naming scheme.

Adrian
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Converting a package to singlespec: two questions

Sebastian-2
In reply to this post by Lee Duncan
On 12/11/2017 01:36 AM, Lee Duncan wrote:
> 1. The package is called "targetcli-fb". Since this does not follow the
> "pyton-PACKAGENAME" convention, what should the python3 version of the
> package be called? Perhaps something like targetcli-fb-python3? or
> "python3-targetcli-fb"? I don't like either.
Is it a package intended to be used only by end-users or does it provide
some library for other programs?
If it is the first: You don't need to singlespec it at all.
> 2. This package installs some stuff that should be invariant with
> respect to python version, such as the directory /etc/target, and the
> systemd service unit file /usr/lib/systemd/system/targetcli.service.
You can use three packages, python2-$name python3-$name and $name and
the last has the static files.


signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Converting a package to singlespec: two questions

Lee Duncan
On 12/11/2017 03:51 AM, Sebastian wrote:
> On 12/11/2017 01:36 AM, Lee Duncan wrote:
>> 1. The package is called "targetcli-fb". Since this does not follow the
>> "pyton-PACKAGENAME" convention, what should the python3 version of the
>> package be called? Perhaps something like targetcli-fb-python3? or
>> "python3-targetcli-fb"? I don't like either.
>
> Is it a package intended to be used only by end-users or does it provide
> some library for other programs?

Yes, only by end-users, as it is at the top of it's software stack, i.e.
no other packages "require" this one, but it requires others, all of
which are available in both python2 and python3 now.

This package currently has several parts:

- the python support library, which needs to be either python2 or
python3 (i.e. in /usr/lib/python*/site-lib/...)

- the man pages

- some other docs that go with all free software (like COPYING, README, etc)

- a user-level command (python script) that goes in /usr/bin

- some meta-data runtime directories (like /etc/target)

- A systemd "unit" file

The first 4 items in this list could be handled by a singlespec
approach, but not the meta-data directory tree nor the systemd unit file.


> If it is the first: You don't need to singlespec it at all.

Even though this is end-user based I still don't see how i can avoid
singlespec, other than just having two different (conflicting) packages.

>> 2. This package installs some stuff that should be invariant with
>> respect to python version, such as the directory /etc/target, and the
>> systemd service unit file /usr/lib/systemd/system/targetcli.service.
>
> You can use three packages, python2-$name python3-$name and $name and
> the last has the static files.
>

That makes sense to me, though it sounds like a bit more work. This is
an existing package.
--
Lee Duncan
SUSE Labs


signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Converting a package to singlespec: two questions

Lee Duncan
In reply to this post by John Paul Adrian Glaubitz


On 12/11/2017 01:52 AM, John Paul Adrian Glaubitz wrote:

> On 12/11/2017 01:36 AM, Lee Duncan wrote:
>> 1. The package is called "targetcli-fb". Since this does not follow the
>> "pyton-PACKAGENAME" convention, what should the python3 version of the
>> package be called? Perhaps something like targetcli-fb-python3? or
>> "python3-targetcli-fb"? I don't like either.
>
> Please use the common python-$PACKAGE naming scheme, anything else would
> just be confusing. Users expect Python packages in openSUSE to follow
> the common naming scheme. If you use something else, your package will
> be harder to find.

Yes, of course that makes sense for a new package, but this package is
already known by this name (targetcli-fb), as it replaces a
long-standing package called "targetcli", and it provides the
command-line program "targetcli". :)

It seems like I could make an alias for the package of python2-NAME (and
python3-NAME), but changing the name seems a bit disruptive.

>
> I also don't know whether python-rpm-macros will actually work with
> packages not following the python-/python3- naming scheme.
>
> Adrian

Well, I may have to break this package into a variant and non-variant
part, in which case I may be free to rename as I see fit.

--
Lee Duncan
SUSE Labs
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Converting a package to singlespec: two questions

Sebastian-2
In reply to this post by Lee Duncan
On 12/11/2017 07:46 PM, Lee Duncan wrote:
>> If it is the first: You don't need to singlespec it at all.
> Even though this is end-user based I still don't see how i can avoid
> singlespec, other than just having two different (conflicting) packages.
Why do you want to singlespec it then at all? I see no reason to do so.

Sebastian

--
python programming - mail server - photo - video - https://sebix.at
cryptographic key at https://sebix.at/DC9B463B.asc and on public keyservers



signature.asc (871 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Converting a package to singlespec: two questions

Lee Duncan


On 12/11/2017 11:00 AM, Sebastian wrote:
> On 12/11/2017 07:46 PM, Lee Duncan wrote:
>>> If it is the first: You don't need to singlespec it at all.
>> Even though this is end-user based I still don't see how i can avoid
>> singlespec, other than just having two different (conflicting) packages.
> Why do you want to singlespec it then at all? I see no reason to do so.
>
> Sebastian
>

It is not a matter of want, really. I was under the impression this had
to be done.

Certainly, python2 is going away, so I need to (and want to) support
python3.

But some users of this package still done have python3, so I'd like to
keep the python2 package around.

I'm now thinking I want to rename the existing package
"python2-targetcli-fb", name the new package "python3-targetcli-fb", and
create an aliases of "targetcli-fb" and "targetcli" for the new version.
That way, if somebody just does a "zypper in targetcli", they will get
the python 3 version. They can still get the python2 version, but under
the new name of "python2-targetcli-fb" only.

The only part I don't like about this is that I have two duplicate
packages to maintain. But the good news is that the maintainence work
for the python2 version will die out.

--
Lee Duncan
SUSE Labs


signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Converting a package to singlespec: two questions

Sebastian-2
On 12/11/2017 08:49 PM, Lee Duncan wrote:

> On 12/11/2017 11:00 AM, Sebastian wrote:
>> On 12/11/2017 07:46 PM, Lee Duncan wrote:
>>>> If it is the first: You don't need to singlespec it at all.
>>> Even though this is end-user based I still don't see how i can avoid
>>> singlespec, other than just having two different (conflicting) packages.
>> Why do you want to singlespec it then at all? I see no reason to do so.
>>
>> Sebastian
>>
> It is not a matter of want, really. I was under the impression this had
> to be done.
In case of your package I am not aware of such a requirement (but I'm
not authoritative).
> But some users of this package still done have python3,
Users not having python3 installed already? What distribution are we
talking about?
And if this is the case: Does it matter if your package is the first one
on their computers that requires python3?

Sebastian

--
python programming - mail server - photo - video - https://sebix.at
cryptographic key at https://sebix.at/DC9B463B.asc and on public keyservers



signature.asc (871 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Converting a package to singlespec: two questions

Simon Lees-3
In reply to this post by Lee Duncan


On 12/12/17 06:19, Lee Duncan wrote:

>
> On 12/11/2017 11:00 AM, Sebastian wrote:
>> On 12/11/2017 07:46 PM, Lee Duncan wrote:
>>>> If it is the first: You don't need to singlespec it at all.
>>> Even though this is end-user based I still don't see how i can avoid
>>> singlespec, other than just having two different (conflicting) packages.
>> Why do you want to singlespec it then at all? I see no reason to do so.
>>
>> Sebastian
>>
>
> It is not a matter of want, really. I was under the impression this had
> to be done.
>
> Certainly, python2 is going away, so I need to (and want to) support
> python3.
>
> But some users of this package still done have python3, so I'd like to
> keep the python2 package around.
>
> I'm now thinking I want to rename the existing package
> "python2-targetcli-fb", name the new package "python3-targetcli-fb", and
> create an aliases of "targetcli-fb" and "targetcli" for the new version.
> That way, if somebody just does a "zypper in targetcli", they will get
> the python 3 version. They can still get the python2 version, but under
> the new name of "python2-targetcli-fb" only.
>
> The only part I don't like about this is that I have two duplicate
> packages to maintain. But the good news is that the maintainence work
> for the python2 version will die out.
>
I'd also just swap it to building for python3 only and keep the package
name, tumbleweed users are almost guaranteed to have python3 installed,
as will SLE-15 / Leap 15 users unless they have such a minimal system
that they have no python. So there is almost no reason to have a python2
version in Factory/Tumbleweed maybe its worth having a version if SLE-12
users are using a newer version via packagehub, but you could probably
do that via updating the version in Leap 42.3 and submitting to
packagehub from there. For any other usecase you could also just keep a
python 2 version somewhere on obs.

But personally I wouldn't make your main package more complicated just
for the sake of some users who are doing things an unofficial way.

--

Simon Lees (Simotek)                            http://simotek.net

Emergency Update Team                           keybase.io/simotek
SUSE Linux                           Adelaide Australia, UTC+10:30
GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B


signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Converting a package to singlespec: two questions

Thomas Bechtold
In reply to this post by Lee Duncan
Hi Lee,

On 11.12.2017 19:46, Lee Duncan wrote:

> On 12/11/2017 03:51 AM, Sebastian wrote:
>> On 12/11/2017 01:36 AM, Lee Duncan wrote:
>>> 1. The package is called "targetcli-fb". Since this does not follow the
>>> "pyton-PACKAGENAME" convention, what should the python3 version of the
>>> package be called? Perhaps something like targetcli-fb-python3? or
>>> "python3-targetcli-fb"? I don't like either.
>>
>> Is it a package intended to be used only by end-users or does it provide
>> some library for other programs?
>
> Yes, only by end-users, as it is at the top of it's software stack, i.e.
> no other packages "require" this one, but it requires others, all of
> which are available in both python2 and python3 now.
>
> This package currently has several parts:
>
> - the python support library, which needs to be either python2 or
> python3 (i.e. in /usr/lib/python*/site-lib/...)
>
> - the man pages
>
> - some other docs that go with all free software (like COPYING, README, etc)
>
> - a user-level command (python script) that goes in /usr/bin
>
> - some meta-data runtime directories (like /etc/target)
>
> - A systemd "unit" file
>
> The first 4 items in this list could be handled by a singlespec
> approach, but not the meta-data directory tree nor the systemd unit file.

Theses can go into a common package which both (python2- and python3-)
packages Require. So you would have 4 binary packages:

- python2-targetcli-fb (which Provides targetcli-fb and Requires
python-targetcli-fb-common)
- python3-targetcli-fb (which Requires python-targetcli-fb-common)
- python-tagetcli-fb-common
- python-targetcli-fb-doc

An example (without the -doc package) would be
https://build.opensuse.org/package/show/devel:languages:python/python-websockify

Best,

Tom
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]