FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > EPEL Development

 
 
LinkBack Thread Tools
 
Old 06-14-2010, 07:48 PM
Stephen Gallagher
 
Default Request for policy clarification

Recently, I've had to deal with a rather touchy situation in EPEL. I
built the package libtalloc of version 2.0.1 as a dependency on several
other packages that I was building: libtevent, libldb and sssd.


This was released and entered EPEL5 stable during the lifetime of RHEL 5.4.

When RHEL 5.5 was released, however, it contained a new package,
samba3x, that built as a subpackage libtalloc 1.2.0. So now there is a
conflict in EPEL, which violates the "EPEL won't upgrade packages in
RHEL" rule.


However, we also have a responsibility to those relying on this package
in EPEL (as libtalloc 1.2.0 is too old to work as the dependency for
libldb or sssd).


My case was somewhat fortunate: libtalloc 2.x had gone through an soname
bump. I was able to (in a very hideous hack) rebuild a copy of libtalloc
1.2.0 from the samba3x SRPM and repackage it into my EPEL libtalloc 2.x
package. Thus, any users who were using e.g. SSSD in EPEL 5 will be able
to update to RHEL 5.6, even if it is in violation of the "EPEL won't
upgrade packages in RHEL" rule.


However, I think we need a general policy written up for EPEL on how we
should handle other packages that end up in this situation. For example,
what do we do if a package has NOT had an soname bump, and some EPEL
packages cannot function with the older version of the library in RHEL?


Obviously, this is a problem that must be solved in EPEL, not in RHEL.
The RHEL policy will always be (and should be) "If you install a
third-party repository, your problems are your own".



* Last note: I am working with the samba3x team at Red Hat to eliminate
this conflict in RHEL 5.6 by pulling libtalloc 2.0.1 into RHEL proper
and building samba3x against it.


--
Stephen Gallagher
RHCE 804006346421761

Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 06-14-2010, 08:03 PM
Dennis Gilmore
 
Default Request for policy clarification

On Monday, June 14, 2010 02:48:59 pm Stephen Gallagher wrote:
> Recently, I've had to deal with a rather touchy situation in EPEL. I
> built the package libtalloc of version 2.0.1 as a dependency on several
> other packages that I was building: libtevent, libldb and sssd.
>
> This was released and entered EPEL5 stable during the lifetime of RHEL 5.4.
>
> When RHEL 5.5 was released, however, it contained a new package,
> samba3x, that built as a subpackage libtalloc 1.2.0. So now there is a
> conflict in EPEL, which violates the "EPEL won't upgrade packages in
> RHEL" rule.
>
> However, we also have a responsibility to those relying on this package
> in EPEL (as libtalloc 1.2.0 is too old to work as the dependency for
> libldb or sssd).
>
> My case was somewhat fortunate: libtalloc 2.x had gone through an soname
> bump. I was able to (in a very hideous hack) rebuild a copy of libtalloc
> 1.2.0 from the samba3x SRPM and repackage it into my EPEL libtalloc 2.x
> package. Thus, any users who were using e.g. SSSD in EPEL 5 will be able
> to update to RHEL 5.6, even if it is in violation of the "EPEL won't
> upgrade packages in RHEL" rule.
this is not at all acceptable and needs to be re done so it is done according
to the letter of the epel guidelines

>
> However, I think we need a general policy written up for EPEL on how we
> should handle other packages that end up in this situation. For example,
> what do we do if a package has NOT had an soname bump, and some EPEL
> packages cannot function with the older version of the library in RHEL?
>
> Obviously, this is a problem that must be solved in EPEL, not in RHEL.
> The RHEL policy will always be (and should be) "If you install a
> third-party repository, your problems are your own".
>
>
> * Last note: I am working with the samba3x team at Red Hat to eliminate
> this conflict in RHEL 5.6 by pulling libtalloc 2.0.1 into RHEL proper
> and building samba3x against it.

The issue has to be fixed by Red Hat, they are the ones that created the
problem they have to fix it we can't. you could package libtalloc2 to not
conflict at all with rhel and allow rhels package to be installed and work fine.


in the instance of rhel doing something that makes a package not work in epel
and there is no way to package things so that they can all live happily and
work we have to remove the package from epel and send an email to the announce
list stating so and why.

This is one of the pain points in having Red Hat go off and do its own thing
and not considering us. we can only work as much magic as we can to make
things work.

Dennis
_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 06-14-2010, 08:29 PM
Toshio Kuratomi
 
Default Request for policy clarification

On Mon, Jun 14, 2010 at 03:48:59PM -0400, Stephen Gallagher wrote:
> Recently, I've had to deal with a rather touchy situation in EPEL. I
> built the package libtalloc of version 2.0.1 as a dependency on
> several other packages that I was building: libtevent, libldb and
> sssd.
>
> This was released and entered EPEL5 stable during the lifetime of RHEL 5.4.
>
> When RHEL 5.5 was released, however, it contained a new package,
> samba3x, that built as a subpackage libtalloc 1.2.0. So now there is
> a conflict in EPEL, which violates the "EPEL won't upgrade packages
> in RHEL" rule.
>
So for this we probably need to ask the RHEL maintainer to bump epoch on
their packages so that it will upgrade the EPEL version.

> However, we also have a responsibility to those relying on this
> package in EPEL (as libtalloc 1.2.0 is too old to work as the
> dependency for libldb or sssd).
>
For this we'd probably want a libtalloc2 package in EPEL.

> My case was somewhat fortunate: libtalloc 2.x had gone through an
> soname bump. I was able to (in a very hideous hack) rebuild a copy of
> libtalloc 1.2.0 from the samba3x SRPM and repackage it into my EPEL
> libtalloc 2.x package. Thus, any users who were using e.g. SSSD in
> EPEL 5 will be able to update to RHEL 5.6, even if it is in violation
> of the "EPEL won't upgrade packages in RHEL" rule.
>
This is probably something we want to change ASAP by getting the talloc2
package in and fixed up. I think in the past we've had to take things out
of EPEL when their dependencies couldn't be met due to a RHEL upgrade. :-(

> However, I think we need a general policy written up for EPEL on how
> we should handle other packages that end up in this situation. For
> example, what do we do if a package has NOT had an soname bump, and
> some EPEL packages cannot function with the older version of the
> library in RHEL?
>
When the EPEL package is new, we end up not being able to submit the EPEL
package as the dependencies cannot be met out of what's available in RHEL.

Perhaps we could do something with RPATH and a private library path in this
case, though. You're probably right that we want to have some rules about
htis so, for example, we'd still build the new library in its own package --
but we'd move the libraries to the private location in %install.

>
> * Last note: I am working with the samba3x team at Red Hat to
> eliminate this conflict in RHEL 5.6 by pulling libtalloc 2.0.1 into
> RHEL proper and building samba3x against it.
>
<nod> That's the thing to do for the fuutre.

-Toshio
_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 06-14-2010, 09:15 PM
Stephen Gallagher
 
Default Request for policy clarification

The issue has to be fixed by Red Hat, they are the ones that created the
problem they have to fix it we can't. you could package libtalloc2 to not
conflict at all with rhel and allow rhels package to be installed and work fine.


in the instance of rhel doing something that makes a package not work in epel
and there is no way to package things so that they can all live happily and
work we have to remove the package from epel and send an email to the announce
list stating so and why.

This is one of the pain points in having Red Hat go off and do its own thing
and not considering us. we can only work as much magic as we can to make
things work.


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.


In my opinion, taking this package out of EPEL (and all of its
descendents, including SSSD which I am aware of being used by a number
of very large deployments) would be far more disruptive than simply
bending the "updating package" rule for a few months.



* This is not a decision I made without the input of many others on
#fedora-devel

--
Stephen Gallagher
RHCE 804006346421761

Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 06-14-2010, 10:46 PM
Toshio Kuratomi
 
Default Request for policy clarification

On Mon, Jun 14, 2010 at 05:15:38PM -0400, Stephen Gallagher wrote:
>
> >The issue has to be fixed by Red Hat, they are the ones that created the
> >problem they have to fix it we can't. you could package libtalloc2 to not
> >conflict at all with rhel and allow rhels package to be installed and work fine.
> >
> >
> >in the instance of rhel doing something that makes a package not work in epel
> >and there is no way to package things so that they can all live happily and
> >work we have to remove the package from epel and send an email to the announce
> >list stating so and why.
> >
> >This is one of the pain points in having Red Hat go off and do its own thing
> >and not considering us. we can only work as much magic as we can to make
> >things work.
>
> 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.

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.

> In my opinion, taking this package out of EPEL (and all of its
> descendents, including SSSD which I am aware of being used by a
> number of very large deployments) would be far more disruptive than
> simply bending the "updating package" rule for a few months.
>
Unless I missed something, there'd be no breakage in the EPEL repository if
you get libtalloc2 in.

>
> * This is not a decision I made without the input of many others on
> #fedora-devel
>
You need to be discussing this on #epel and in this mailing list and the
packagers of epel (including yourself) can then come to a unified decision.
What you've done is say that the rules of epel don't apply to your package
without getting buyin from the other people who have to live by the rules
which is disrespectful of them.

* Note: not arguing that the rule shouldn't be changed (although I don't
think that it's waranted i nthis instance), just that deciding to ignore
it for your package is the wrong way to approach the problem.
_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 06-14-2010, 10:56 PM
seth vidal
 
Default Request for policy clarification

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


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



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


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

That's the problem!

-sv


_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 06-14-2010, 11:49 PM
Toshio Kuratomi
 
Default Request for policy clarification

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
_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 06-15-2010, 06:49 AM
David Juran
 
Default Request for policy clarification

On Mon, 2010-06-14 at 15:48 -0400, Stephen Gallagher wrote:

> My case was somewhat fortunate: libtalloc 2.x had gone through an soname
> bump.

Maybe this is a bit off-topic, but isn't an API change without an
accompanying bump in soname a bug
(http://www.gnu.org/software/libtool/manual/libtool.html#Libtool-versioning) ? As such it shouldn't happen and if it does, it should be treated as a bug and fixed.

--
David Juran
Sr. Consultant
Red Hat
+358-504-146348
_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 06-15-2010, 11:14 AM
Stephen Gallagher
 
Default Request for policy clarification

On 06/15/2010 02:49 AM, David Juran wrote:

On Mon, 2010-06-14 at 15:48 -0400, Stephen Gallagher wrote:


My case was somewhat fortunate: libtalloc 2.x had gone through an soname
bump.


Maybe this is a bit off-topic, but isn't an API change without an
accompanying bump in soname a bug
(http://www.gnu.org/software/libtool/manual/libtool.html#Libtool-versioning) ? As such it shouldn't happen and if it does, it should be treated as a bug and fixed.


A backwards-compatible change in API (e.g. adding a completely NEW
function) does not warrant an soname bump. However, libtalloc 2 changed
the arguments of a couple functions, and as a result the soname was bumped.


--
Stephen Gallagher
RHCE 804006346421761

Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 06-16-2010, 02:58 PM
seth vidal
 
Default Request for policy clarification

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


_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 

Thread Tools




All times are GMT. The time now is 11:45 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org