Request for policy clarification

Toshio Kuratomi a.badger at gmail.com
Wed Jun 16 15:30:28 UTC 2010


On Wed, Jun 16, 2010 at 10:58:39AM -0400, seth vidal wrote:
> On Mon, 2010-06-14 at 19:49 -0400, Toshio Kuratomi wrote:
> 
> > > 
> > > 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.
> 
> Like what?
> 
I listed it in the bullet entry for the suggestion to put these both in
a single package.

> > Policy should never be ignored.
> 
> I disagree. Policy is a guideline, nothing more.
> 
Policy is the rules under which people agree to work together.  When you
have policies that you simply ignore then you end up with people pointing at
your ignoring of policy as a valid reason for you to ignore policy.  That's
why I wrote the second stanze about changing policy.  when you update the
policy to reflect the realities that you face, then you make the policies
better for everyone who is trying to make better packaging choices.

> > * 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)
> 
> not a good option b/c it breaks user.
>
Right.

> > 
> > * 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.
> 
> We've intentionally left users broken? Wow, that's classy.
> 
Yes.  Which is why I think that the policies here should be changed.

> 
> > * 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.
> 
> Why introduce a package? How does this make it easier/better than just
> introducing the RIGHT dep into the existing pkg?
> 
I explained below when I listed the additional drawback of putting things in a single
package.


> With a package you have a lot more garbage to maintain - with just
> adding the dep you can phase it out in an update and not have to add any
> obsoletes or conflicts garbage.
> 
This argument could be used for every compat package in Fedora as well,
though.  Why don't we ship the openssl compat package and the main openssl
packages from a single srpm?

-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/2692b1fd/attachment.sig>


More information about the epel-devel-list mailing list