On Sat, Feb 18, 2017 at 4:54 AM, Dominik 'Rathann' Mierzejewski <dominik@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxx> 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. _______________________________________________ packaging mailing list -- packaging@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to packaging-leave@xxxxxxxxxxxxxxxxxxxxxxx
