On Sat, Feb 18, 2017 at 4:54 AM, Dominik 'Rathann' Mierzejewski
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(a)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
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