Request for policy clarification

[Toshio Kuratomi]

On Mon, Jun 14, 2010 at 06:56:27PM -0400, seth vidal wrote:
> On Mon, 2010-06-14 at 18:46 -0400, Toshio Kuratomi wrote:
> > > 
> > > Well, in this particular instance, given that the two versions of the
> > > package had different sonames, I judged* that the rule of "Don't
> > > break existing deployments" was more important than the rule of
> > > "Don't upgrade RHEL packages" in this case. My EPEL package is
> > > bundling a compatible version of the older soname (built directly
> > > from the sources in the RHEL SRPM) so as to minimize the damage until
> > > RHEL 5.6 can sort this out properly.
> > > 
> > This isn't how it works.  You have the ability to fix this by creating the
> > libtalloc2 package in EPEL5.  So you've broken the expectations of users
> > using EPEL without a reason.
> 
> What the hell? 
> 
> I don't think you understand the order of ops:
> 
> 1. there was a libtalloc in epel
>    there was no libtalloc in rhel
> 2. rhel5.5 came out
>    libtalloc came out of samba3x in rhel
>    the version of libtalloc in samba3x (in rhel)has ALWAYS been older   
>    than the  one in epel.
>    the version of libtalloc in rhel is not even a normal libtalloc it 
>    is a special one
> 
No, I understand this part.

> 
> So if he introduces a libtalloc in epel to fix this he can carry the
> libtalloc from rhel, temporarily, to do so. B/c the samba3x pkger has
> already agreed to fix this in rhel 5.6
> 
This is not without cost, though.
> 
> 
> > 
> > EPEL has already judged that breaking existing deployments is the lesser
> > evil compared to replacing packages in RHEL so you'd need to discuss the
> > idea with the other packagers in EPEL and decide on whether the policy
> > should change rather than ignoring the policy.
> 
> I think the policy should be ignored in this case. we're leaving systems
> broken  and making it so that 'yum install samba3x' will not work on
> rhel5.5 systems  w/epel enabled for the next 4-5months.
> 
Policy should never be ignored.

Policy should be changed to fit the realities of the situation.

> 
> > Unless I missed something, there'd be no breakage in the EPEL repository if
> > you get libtalloc2 in.
> 
> Except you have to obsolete the older pkg to keep from breaking existing
> installs.
> 
yeah -- this is what I was missing -- the RHEL packager had a bunch of
options to not break things or even not break things for RHEL:  Could have
used epoch (breaks EPEL), could have made a libtalloc1 package (no
breakage), could have packaged, ported, and built against libtalloc-2.x (no
breakage).

Instead they packaged libtalloc-1.x as libtalloc.  This means that anyone
with EPEL repositories enabled will have this broken for them.  At this
point, these are our options:

* Remove libtalloc-2.x from our repositories and anything that depends on
it.
  - This is what we've done in the past.  It leaves people who are upgrading
    from RHEL-5.4 broken as they still have the old talloc on the system.
    It prevents people who want to have the talloc-2.x dependent packages
    from getting updates (EPEL doesn't provide them anymore)

* Create a talloc2-2.x package and remove the talloc-2.x package from EPEL.
  - This will leave broken people who already have libtalloc-2.x from EPEL
    installed.  It will not lead to new breakage for people who have not yet
    installed libtalloc from EPEL.  We only maintain the talloc-2 package;
    talloc-1.x is maintained by the RHEL maintainers.  This is also what
    we've done i nthe past where the ability resides.

* Create a talloc1-1.x package and leave libtalloc-2.x in EPEL.
  - As long as the RHEL package is using the automatic library provides,
    I think this would work, right?  The samba package will require
    libtalloc.so.1 which is provided by this package.  The current EPEL
    packages will require libtalloc.so.2 which is provided by the current
    EPEL libtalloc-2.x package.  This means that we are put on the hook for
    maintaining the libtalloc1 packages through security issues, bugfixes,
    problems that the RHEL maintainers solve in their talloc1 package, etc.
    Having a constant dialog with the RHEL maintainers to get their changes
    into our package simultaneously seems like the best step here.  It also
    means that we make the job of Red Hat support harder but they can fall
    back on the "You have a third party repo installed, please uninstall
    those packages" if the customer is willing.

* Bundle libtalloc-1.x and libtalloc-2.x in a single package.
  - I don't see any advantage to this over the previous suggestion and there
    is the additional drawback that an update to one of libtalloc-1 or
    libtalloc-2 requires that users get a needless update to the other one.
    So why should we do this?

As for the initial inquiry about clarifying the policy, the polciy is quite
clear as to what to do here; the policy instead needs changing.  I'd
proposee that the updated policy makes the following points::

* How to coordinate efforts between the RHEL and EPEL maintainers.
* How should the new package's version and release compare to the RHEL
  package version and release?
* Should the new package be constrained in source or spec file contents (for
  instance, it needs to be bug-for-bug compatible with the RHEL version)?
* Are there specific provides, obsoletes, conflicts, requires that the
  packages in this situation are required to have?
* When the two packages would conflict (because of having the same SONAME,
  for instance) is there a policy for that (Private library shared between
  the EPEL packages) or do we fall back to the old policy of removing the
  library and the dependent packages?

-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/20100614/bf7361ab/attachment.sig>