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