Request for policy clarification

[Toshio Kuratomi]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/epel-devel-list/attachments/20100616/7b6a104f/attachment.sig>