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-16-2010, 03:30 PM
Toshio Kuratomi
 
Default Request for policy clarification

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
_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 06-16-2010, 03:35 PM
seth vidal
 
Default Request for policy clarification

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


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

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
_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 06-16-2010, 04:17 PM
seth vidal
 
Default Request for policy clarification

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


_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 06-16-2010, 05:23 PM
Stephen John Smoogen
 
Default Request for policy clarification

On Wed, Jun 16, 2010 at 9:35 AM, seth vidal <skvidal@fedoraproject.org> 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

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

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_Conflicting_Packa ges

"""
* 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
_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 06-16-2010, 06:04 PM
Toshio Kuratomi
 
Default Request for policy clarification

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@fedoraproject.org> 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.
_______________________________________________
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 07:47 PM.

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