Request for policy clarification

[Stephen Gallagher]

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/

[Dennis Gilmore]

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

[Stephen Gallagher]

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

[Toshio Kuratomi]

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.

[Seth Vidal]

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

[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

[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

[Toshio Kuratomi]

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

[Seth Vidal]

On Wed, 2010-06-16 at 11:30 -0400, Toshio Kuratomi wrote:
>  > 
>  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. 
Right - we've had this discussion before.

Rules have power b/c we give them to them. They are not empowered on
their own.

That is a political-philosophy question :)


>  > 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? 
B/c the openssl items are not on a horizon that is as a short as
6months.

This problem goes away when samba3x gets fixed.

-sv

[Toshio Kuratomi]

On Wed, Jun 16, 2010 at 11:35:09AM -0400, seth vidal wrote:
>  On Wed, 2010-06-16 at 11:30 -0400, Toshio Kuratomi wrote:
>  > > 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?
>  
>  B/c the openssl items are not on a horizon that is as a short as
>  6months.
>   
I don't understand this phrasing.  Could you restate?

>  This problem goes away when samba3x gets fixed.
>  
>  
Yes, in RHEL-5.6 IIUC and it goes as planned.

-Toshio

[Seth Vidal]

On Wed, 2010-06-16 at 12:13 -0400, Toshio Kuratomi wrote:
>  > B/c the openssl items are not on a horizon that is as a short
> as
>  > 6months.
>  > 
>  I don't understand this phrasing.  Could you restate? 
openssl-compat is in a separate pkg b/c we never know if we will ever
get rid of it.

the sundown for the openssl-compat is never, afaict.


>  > This problem goes away when samba3x gets fixed.
>  > 
>  >
>  Yes, in RHEL-5.6 IIUC and it goes as planned. 

Right - which means maintaining the libtalloc compat-inside for only 5-6
months.

-sv

[Toshio Kuratomi]

On Wed, Jun 16, 2010 at 12:17:22PM -0400, seth vidal wrote:
>  On Wed, 2010-06-16 at 12:13 -0400, Toshio Kuratomi wrote:
>  > > B/c the openssl items are not on a horizon that is as a short as
>  > > 6months.
>  > > 
>  > I don't understand this phrasing.  Could you restate?
>  
>  openssl-compat is in a separate pkg b/c we never know if we will ever
>  get rid of it.
>  
>  the sundown for the openssl-compat is never, afaict.
>
>  
>  > > This problem goes away when samba3x gets fixed.
>  > > 
>  > >
>  > Yes, in RHEL-5.6 IIUC and it goes as planned.
>  
>  
>  Right - which means maintaining the libtalloc compat-inside for only 5-6
>  months.
>   
Alrighty.  I propose adding to this page as 1.1.8.5:
https://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies

"""
Since RHEL minor releases are only maintained for a period of 6 months,
packages may disregard the Fedora prohibition against bundling libraries if:

1) The bundling is done to fix a problem with EPEL packages depending on
incompatible versions of a library introduced by a new RHEL package that was
not present in previous EPEL builds.

2) You have a commitment from the RHEL maintainers that the issue will be
fixed at the next RHEL-X.Y release so the bundling will stop when the new
RHEL minor version is released in six months.

3) The bundling is done to enable a compatible library version and is
shipped inside of the current library package.

When you bundle a compatible library version like this, open a bug in
bugzilla against the library, in the appropriate EPEL version, and have it
block [SETUP BLOCKER BUG IN BUGZILLA FOR THIS].   Old bugs need to be
cleared when the RHEL packages for the new RHEL-minor version enter the
buildroot.  The EPEL steering committee will evaluate any bug that does not
close at that time and decide whether to push it forward or force the compat
package to be unbundled.
"""

FWIW, I wouldn't vote to approve this kind of Guideline for Fedora but if
6 months is seen as being a cutoff date in EPEL, then I think it captures
the requirements.


That still leaves an update to the guidelines for not overriding a RHEL
package.  Here's a start for this section:

https://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#Policy_for_Conf...

"""
* Generally, EPEL packages must not conflict with packages in RHEL Base (Including
  Advanced Platform).  EPEL packages are allowed to conflict if these
  criteria are met:

  1) EPEL packages that were previously working are broken by a RHEL update
  or RHEL packages are broken due to not taking into account users that may
  have EPEL packages installed on their system.

  2) Fixing the problem merely involves repackaging the existing RHEL
  package and the existing EPEL packages in such a way that the depsolver will
  find both as appropriate.

  When you do this, you need to closely track the status of the RHEL package
  you are bundling as you are overriding that package in EPEL.  So if a new
  RHEL package is released, you need to be able to produce new EPEL packages
  with little lag.
"""

This doesn't address all the points I raised earlier, though.  So someone
with time needs to continue working on it.

-Toshio

[Stephen John Smoogen]

On Wed, Jun 16, 2010 at 9:35 AM, seth vidal <skvidal(a)fedoraproject.org&gt; wrote:
>  On Wed, 2010-06-16 at 11:30 -0400, Toshio Kuratomi wrote:
> > >
> > 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.
>
>  Right - we've had this discussion before.
>
>  Rules have power b/c we give them to them. They are not empowered on
>  their own.
>
>  That is a political-philosophy question :) 
How about we just keep ti to an etymological one. In the lingo of
RFC's, policies are MUST and guidelines are SHOULD. Who empowers them
etc can stay with this evenings argument on how many angels dance on
the head of a pin.

As it stands, we have written certain things as MUST and should
rewrite them as SHOULD or rewrite them altogether.

-- 
Stephen J Smoogen.
“The core skill of innovators is error recovery, not failure avoidance.”
Randy Nelson, President of Pixar University.
"We have a strategic plan. It's called doing things.""
— Herb Kelleher, founder Southwest Airlines

[Toshio Kuratomi]

On Wed, Jun 16, 2010 at 11:23:09AM -0600, Stephen John Smoogen wrote:
>  On Wed, Jun 16, 2010 at 9:35 AM, seth vidal
> <skvidal(a)fedoraproject.org&gt; wrote:
>  > On Wed, 2010-06-16 at 11:30 -0400, Toshio Kuratomi wrote:
>  >> >
>  >> 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.
>  >
>  > Right - we've had this discussion before.
>  >
>  > Rules have power b/c we give them to them. They are not empowered on
>  > their own.
>  >
>  > That is a political-philosophy question :)
>  
>  How about we just keep ti to an etymological one. In the lingo of
>  RFC's, policies are MUST and guidelines are SHOULD. Who empowers them
>  etc can stay with this evenings argument on how many angels dance on
>  the head of a pin.
>  
>  As it stands, we have written certain things as MUST and should
>  rewrite them as SHOULD or rewrite them altogether.
>   
EPEL and FESCO has policies, The FPC makes policies that are labeled as
Guidelines.  Some of the FPC Guidelines use should and must in laymen's
terms rather than RFC terms.  So we should rename the packaging guidelines
to packaging policy and then someone needs to proofread the guidelines for
every use of should and must.  (although I think the bolded should and musts
are consistent in the FPG)

-Toshio.

[Toshio Kuratomi]

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

[David Juran]

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
[phone]

[Stephen Gallagher]

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/