On Wed, Jun 16, 2010 at 12:17:22PM -0400, seth vidal wrote: > On Wed, 2010-06-16 at 12:13 -0400, Toshio Kuratomi wrote: > > > B/c the openssl items are not on a horizon that is as a short as > > > 6months. > > > > > I don't understand this phrasing. Could you restate? > > openssl-compat is in a separate pkg b/c we never know if we will ever > get rid of it. > > the sundown for the openssl-compat is never, afaict. > > > > > This problem goes away when samba3x gets fixed. > > > > > > > > Yes, in RHEL-5.6 IIUC and it goes as planned. > > > Right - which means maintaining the libtalloc compat-inside for only 5-6 > months. > Alrighty. I propose adding to this page as 1.1.8.5: https://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies
""" Since RHEL minor releases are only maintained for a period of 6 months, packages may disregard the Fedora prohibition against bundling libraries if: 1) The bundling is done to fix a problem with EPEL packages depending on incompatible versions of a library introduced by a new RHEL package that was not present in previous EPEL builds. 2) You have a commitment from the RHEL maintainers that the issue will be fixed at the next RHEL-X.Y release so the bundling will stop when the new RHEL minor version is released in six months. 3) The bundling is done to enable a compatible library version and is shipped inside of the current library package. When you bundle a compatible library version like this, open a bug in bugzilla against the library, in the appropriate EPEL version, and have it block [SETUP BLOCKER BUG IN BUGZILLA FOR THIS]. Old bugs need to be cleared when the RHEL packages for the new RHEL-minor version enter the buildroot. The EPEL steering committee will evaluate any bug that does not close at that time and decide whether to push it forward or force the compat package to be unbundled. """ FWIW, I wouldn't vote to approve this kind of Guideline for Fedora but if 6 months is seen as being a cutoff date in EPEL, then I think it captures the requirements. That still leaves an update to the guidelines for not overriding a RHEL package. Here's a start for this section: https://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#Policy_for_Conflicting_Packages """ * Generally, EPEL packages must not conflict with packages in RHEL Base (Including Advanced Platform). EPEL packages are allowed to conflict if these criteria are met: 1) EPEL packages that were previously working are broken by a RHEL update or RHEL packages are broken due to not taking into account users that may have EPEL packages installed on their system. 2) Fixing the problem merely involves repackaging the existing RHEL package and the existing EPEL packages in such a way that the depsolver will find both as appropriate. When you do this, you need to closely track the status of the RHEL package you are bundling as you are overriding that package in EPEL. So if a new RHEL package is released, you need to be able to produce new EPEL packages with little lag. """ This doesn't address all the points I raised earlier, though. So someone with time needs to continue working on it. -Toshio
pgpjRPHZW7O24.pgp
Description: PGP signature
_______________________________________________ epel-devel-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/epel-devel-list
