Hello,
Package names play an important role for the resolution of software dependencies.
I came along another example for a specific name pattern.
https://admin.fedoraproject.org/pkgdb/package/rpms/libXScrnSaver/
This name does not include a main version number so far. Are there any circumstances when this technical detail will matter more?
Regards, Markus
Hello,
On Wednesday, 15 February 2017 at 20:56, Markus Elfring wrote:
Hello,
Package names play an important role for the resolution of software dependencies.
I came along another example for a specific name pattern.
https://admin.fedoraproject.org/pkgdb/package/rpms/libXScrnSaver/
This name does not include a main version number so far. Are there any circumstances when this technical detail will matter more?
I'm not sure I understand your question. Are you asking under what circumstances you should put the version number in the package name?
If yes, then I think this section answers that question: https://fedoraproject.org/wiki/Packaging:Naming#Multiple_packages_with_the_s...
If not, the please rephrase the question.
Regards, Dominik
Are you asking under what circumstances you should put the version number in the package name?
Yes.
https://fedoraproject.org/wiki/Packaging:Naming#Multiple_packages_with_the_s...
Thanks for your link to the guidelines.
I find that a bit of advice is missing there if it will be helpful to integrate extra version data also in package names just before other users would fiddle with the simultaneous installation of package variants.
* Are there any more development challenges to consider for occasional name adjustments?
* How much do you care if the name selection will be finally consistent (including the base name) across software distributions which work with the RPM data format?
Regards, Markus
On Thursday, 16 February 2017 at 17:13, Markus Elfring wrote: [...]
https://fedoraproject.org/wiki/Packaging:Naming#Multiple_packages_with_the_s...
Thanks for your link to the guidelines.
I find that a bit of advice is missing there if it will be helpful to integrate extra version data also in package names just before other users would fiddle with the simultaneous installation of package variants.
As the guidelines say, we try to have only the latest version of a given package in Fedora. Having a version in the package name should be used only in case of different parallel-installable major versions of the same software.
- Are there any more development challenges to consider for occasional name adjustments?
Each new package name needs a review.
- How much do you care if the name selection will be finally consistent (including the base name) across software distributions which work with the RPM data format?
It would be nice if packages were named consistently across RPM-based distributions, but what's your point?
Regards, Dominik
Having a version in the package name should be used only in case of different parallel-installable major versions of the same software.
How often would you like to support parallel installation before a subsequent major version will become generally available?
It would be nice if packages were named consistently across RPM-based distributions, but what's your point?
How do you think about possible consequences around a package name like “libXss1”? https://build.opensuse.org/package/view_file/openSUSE:Factory/libXScrnSaver/...
Regards, Markus
On Thursday, 16 February 2017 at 23:30, Markus Elfring wrote:
Having a version in the package name should be used only in case of different parallel-installable major versions of the same software.
How often would you like to support parallel installation before a subsequent major version will become generally available?
Why would we want to support parallel installation of something that isn't available? I don't understand the question.
It would be nice if packages were named consistently across RPM-based distributions, but what's your point?
How do you think about possible consequences around a package name like “libXss1”? https://build.opensuse.org/package/view_file/openSUSE:Factory/libXScrnSaver/...
Again, I don't get your point at all. libXScrnSaver is packaged in Fedora already.
PS. Obviously, English isn't your primary language and there's a communication barrier here, because I don't understand what you're trying to say at all. Please try to be clearer, maybe by phrasing your questions in a different way. Alternatively, you can come talk to us on IRC. Real-time communications usually yield better results.
Regards, Dominik
On Fri, Feb 17, 2017 at 5:18 PM, Dominik 'Rathann' Mierzejewski dominik@greysector.net wrote:
On Thursday, 16 February 2017 at 23:30, Markus Elfring wrote:
Having a version in the package name should be used only in case of different parallel-installable major versions of the same software.
How often would you like to support parallel installation before a subsequent major version will become generally available?
Why would we want to support parallel installation of something that isn't available? I don't understand the question.
It's been quite common. Major component updates often discard libraries that are required for other stable, existing components that have not yet been updated with nor are compatible with the newer versions and that may be desirable for developers on an existing stable Fedora release. Examples that leap to mind include gcc, RT, openssl, and Python.
It would be nice if packages were named consistently across RPM-based distributions, but what's your point?
How do you think about possible consequences around a package name like “libXss1”? https://build.opensuse.org/package/view_file/openSUSE:Factory/libXScrnSaver/...
Again, I don't get your point at all. libXScrnSaver is packaged in Fedora already.
PS. Obviously, English isn't your primary language and there's a communication barrier here, because I don't understand what you're trying to say at all. Please try to be clearer, maybe by phrasing your questions in a different way. Alternatively, you can come talk to us on IRC. Real-time communications usually yield better results.
Regards, Dominik -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" _______________________________________________ packaging mailing list -- packaging@lists.fedoraproject.org To unsubscribe send an email to packaging-leave@lists.fedoraproject.org
On Saturday, 18 February 2017 at 01:35, Nico Kadel-Garcia wrote:
On Fri, Feb 17, 2017 at 5:18 PM, Dominik 'Rathann' Mierzejewski dominik@greysector.net wrote:
On Thursday, 16 February 2017 at 23:30, Markus Elfring wrote:
Having a version in the package name should be used only in case of different parallel-installable major versions of the same software.
How often would you like to support parallel installation before a subsequent major version will become generally available?
Why would we want to support parallel installation of something that isn't available? I don't understand the question.
It's been quite common. Major component updates often discard libraries that are required for other stable, existing components that have not yet been updated with nor are compatible with the newer versions and that may be desirable for developers on an existing stable Fedora release. Examples that leap to mind include gcc, RT, openssl, and Python.
Except you're talking about two major versions being available at the same time. Markus asked about supporting parallel installation before the next version is available. I don't see the point in the latter case.
Regards, Dominik
On Sat, Feb 18, 2017 at 4:54 AM, Dominik 'Rathann' Mierzejewski dominik@greysector.net wrote:
On Saturday, 18 February 2017 at 01:35, Nico Kadel-Garcia wrote:
On Fri, Feb 17, 2017 at 5:18 PM, Dominik 'Rathann' Mierzejewski dominik@greysector.net wrote:
On Thursday, 16 February 2017 at 23:30, Markus Elfring wrote:
Having a version in the package name should be used only in case of different parallel-installable major versions of the same software.
How often would you like to support parallel installation before a subsequent major version will become generally available?
Why would we want to support parallel installation of something that isn't available? I don't understand the question.
It's been quite common. Major component updates often discard libraries that are required for other stable, existing components that have not yet been updated with nor are compatible with the newer versions and that may be desirable for developers on an existing stable Fedora release. Examples that leap to mind include gcc, RT, openssl, and Python.
Except you're talking about two major versions being available at the same time. Markus asked about supporting parallel installation before the next version is available. I don't see the point in the latter case.
Regards, Dominik
I was responding to your point. "Why would we want to support parallel installation of something that isn't available?" I'm not suggesting that it be done lightly, but there have been a surprising number of times in software history where minor version updates can be incompatible with the primary release, and where providing a testable, development update for a testing environment are useful. And not all software packages are good about setting release numbers in the source code with quite large and incompatible changes. I'm not suggesting that it should be a common practice: But it's at the core of what RHEL publishes with the "software collections", and I've certainly had to publish, for internal use, minor release updates of select components for internal components in Fedora environments.
Samba right now is actually a good case for this. The latest versions of Samba 4.5.x require gnutls-3.4.7 or later. If you'd like to test a Samba release candidate on a Fedora 25 box, you've got to either replace gnutls, which is exceedingly dangerous, or put in a parallel installation of it somewhere to even compile the current Samba release candidate. Supporting parallel development libraries require tought and testability.
libXScrnSaver is packaged in Fedora already.
How do you think about to compare this approach with a specification from an other RPM-based software distribution? https://build.opensuse.org/package/view_file/openSUSE:Factory/libXScrnSaver/...
How are the chances to use a package name like “libXss1” in more places?
PS. Obviously, English isn't your primary language
This is true.
and there's a communication barrier here,
Communication difficulties can often occur.
because I don't understand what you're trying to say at all.
I am trying to check possibilities for name adjustments.
Please try to be clearer, maybe by phrasing your questions in a different way.
Would you like to help in consistent packaging of a software like “Jitsi Desktop 2.10”? http://lists.jitsi.org/pipermail/users/2017-February/012291.html
Real-time communications usually yield better results.
I imagine that corresponding results would be different if the dialogue could be performed also with audio (and video).
Regards, Markus
On Sat, Feb 18, 2017 at 1:13 PM, Markus Elfring < elfring@users.sourceforge.net> wrote:
libXScrnSaver is packaged in Fedora already.
How do you think about to compare this approach with a specification from an other RPM-based software distribution? https://build.opensuse.org/package/view_file/openSUSE: Factory/libXScrnSaver/libXScrnSaver.spec?expand=1
How are the chances to use a package name like “libXss1” in more places?
PS. Obviously, English isn't your primary language
This is true.
and there's a communication barrier here,
Communication difficulties can often occur.
because I don't understand what you're trying to say at all.
I am trying to check possibilities for name adjustments.
Please try to be clearer, maybe by phrasing your questions in a different way.
Would you like to help in consistent packaging of a software like “Jitsi Desktop 2.10”? http://lists.jitsi.org/pipermail/users/2017-February/012291.html
The solution is to package your program officially **inside** of the distributions so for Fedora/EPEL see https://fedoraproject.org/wiki/Package_Review_Process If an RPM package lives outside of the distributions it will be probably in a broken state very often, because things in a distribution base change all the time.
If you really want to build and maintain RPMS outside of the distributions then the solution is to use conditionals like %if 0%{?fedora} your spec file: https://en.opensuse.org/openSUSE:Build_Service_cross_distribution_howto
Marcin
Real-time communications usually yield better results.
I imagine that corresponding results would be different if the dialogue could be performed also with audio (and video).
Regards, Markus _______________________________________________ packaging mailing list -- packaging@lists.fedoraproject.org To unsubscribe send an email to packaging-leave@lists.fedoraproject.org
packaging@lists.fedoraproject.org
-
Dominik 'Rathann' Mierzejewski -
Marcin Dulak -
Markus Elfring -
Nico Kadel-Garcia