On 08/02/2017 07:27 AM, hw wrote: > Jonathan Billings wrote: >> On Jul 28, 2017, at 1:56 PM, hw <hw at gc-24.de> wrote: >>> Are you sure that all the added complexity and implicitly giving up a >>> stable platform by providing a mess of package versions is worth it? >>> How >>> are the plans about dealing with bug reports, say, for squid 2.7, for >>> those who need that version for a feature which hasnīt been included in >>> current versions yet? Just wait a bit until the distribution goes EOL? >>> Is RH going to fix them once someone has bought their support? >> >> >> I’m confused, are you talking about Gentoo, Fedora, CentOS or RHEL? > > I´m talking about Centos here and am referring to experiences with other > distributions at the same time. > > Like Gentoo is great but horrible to keep up to date, and in doing so, > you are expected to become a package manager yourself. Things introduced > into Fedora might make their way into RHEL/Centos, and introducing > multiversion-packages into Fedora might lead to introducing them into > Centos. > > Once they have been introduced, we need to become package managers much as > with Gentoo in order to figure out which versions of which packages work > together. And that´s just the tip of the iceberg. > > What will happen when you report a bug in version N of package foo, perhaps > a bug that was fixed in version N+2? Are they going to fix it, or will > they > wait until the distribution goes EOL and/or tell you to use version N+2 --- > which you can´t use because feature X is missing in that version, which is > why you are using version N. > > Being able to use that very version N is the point of > multiversion-packages. > Not maintaining all provided versions of such packages accordingly would > defeat the whole purpose. > > Perhaps issues like this haven´t been considered yet, that´s why I´m > providing feedback as was asked for, after finding out that the form they > have prepared to get feedback doesn´t allow to do so. I´m aware that this > is feedback they don´t want to hear and will either ignore or encounter > with > unkindness. > > Perhaps I´m entirely wrong and misunderstanding what they´re trying to do, > yet so far nobody has said so. In CentOS for the Base OS, our package management / versioning is quite simple. If it is in RHEL source code for RHEL, we build it as is .. whatever the version. If it works the same in CentOS as in RHEL (even if that is broken), we release it. Our goal is fully functional compatibility with exactly the same versions as the RHEL source code and the same behavior that RHEL exhibits. So, we really don't make versioning decisions or do techincal fixes, we change a bare minimum to make sure people know they are using CentOS Linux (and to meet the Red Hat branding requirements for RHEL). Getting things fixed in CentOS Linux means informing the Red Hat team that the source code contains bugs (either through Fedora or RHEL sections of the Red Hat bugzilla) and getting them fixed upstream, when the fix is released in RHEL, we will incorporate it in CentOS Linux. For the Special Interest Groups (SIGs) things are much different. They are doing real development .. making versioning decisions, etc. Some of the things in SIGs have an upstream at Red Hat, some do not (for example, there is a Xen4CentOS in the Virt SIG that maintains Xen on CentOS Linux 6 and 7 .. that does not exist at all for RHEL). We maintain Xen dom0 kernel is unique in that SIG. User feedback is important, but one has to make it to the proper place. For SIGs, that is bugs.centos.org. For base CentOS Linux .. unless we introduced a bug in building (not usually the case), those are better addressed with the upstream package maintainer (usually RHEL or Fedora bugs). -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: <http://lists.centos.org/pipermail/centos/attachments/20170802/af983f09/attachment-0004.sig>