Request for policy clarification

[seth vidal]

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?

> Policy should never be ignored.

I disagree. Policy is a guideline, nothing more.


> * 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.

> 
> * 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.


> * 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?

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.

-sv