[opensuse-packaging] Converting a package to singlespec: two questions
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: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
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: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
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: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
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
On 12/11/2017 01:36 AM, Lee Duncan wrote: the last has the static files.
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
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
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
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
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
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-websoc... Best, Tom -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
participants (5)
-
John Paul Adrian Glaubitz -
Lee Duncan -
Sebastian -
Simon Lees -
Thomas Bechtold