Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   EPEL Development (http://www.linux-archive.org/epel-development/)
-   -   Overlap policy v20120615 (http://www.linux-archive.org/epel-development/676233-overlap-policy-v20120615.html)

"Richard W.M. Jones" 06-23-2012 03:51 PM

Overlap policy v20120615
 
On Fri, Jun 15, 2012 at 10:43:54AM -0600, Kevin Fenzi wrote:
> Ok, here's another attempt at an overlap policy.
>
> I'd like to ask folks to comment on it again, but please... I'm a
> technical person. I like technical arguments. If you don't like this
> policy, please propose an alternate one you like better and tell us
> why. Or if you like this policy ok, but changing some wording would
> make it much more acceptable, tell us that.
>
> ok? Here's another stab at it:
>
> "EPEL6 will not normally ship packages that are shipped already in the
> following RHEL channels: os, optional, lb, and ha. Any overlapping
> packages must be to provide binary packages on arches not provided by
> RHEL ( following:
> http://fedoraproject.org/wiki/EPEL:Packaging#Limited_Arch_Packages ).
> Additional channels may be added to this list, based on a criteria the
> EPEL sig has yet to decide on."

Kevin, about the provision to provide packages for other binary
architectures.

RHEL 6 supplies qemu-kvm only on x86-64. This provision lets us
provide qemu-kvm on i386 and ppc64 I think.

My questions:

Does it have to be the same n-v-r of qemu-kvm? (This seems like it
would be impossible in practice, so I guess the answer must be no)

Can the other arches be provided by a differently named package? (We
call it 'qemu' in Fedora)

Can the EPEL package override the x86-64 package from RHEL, eg. by
providing qemu-kvm.x86-64 with a higher n-v-r? Or should the EPEL
package ExcludeArch the RHEL packages that exist?

Rich.


--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top

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

inode0 06-23-2012 04:29 PM

Overlap policy v20120615
 
On Fri, Jun 15, 2012 at 5:14 PM, Toshio Kuratomi <a.badger@gmail.com> wrote:
> If you can list for us what actual channels are the equivalent of the old
> AS/AP then we have something else that we can try to use to define logically
> which channels should not be overlapped with. *If you've found this
> information somewhere then giving it to us will be a valuable addition to
> the conversation. *Otherwise, we'll have to continue to assume that there
> isn't an actual understanding of what that is and we'll have to continue to
> try to define it ourselves with a somewhat arbitrary division.

I am willing to do some work here to attempt to sort this out since I
think having a clear policy that EPEL users understand is worth the
bother. I have media going back to RHEL3 and can sort through what
came on it, which I think is a fair definition of what is part of
"RHEL" proper prior to the release of RHEL6.

I do want to observe that there was a media change in RHEL5 which
added some things to the media which required entitlements that go
beyond a RHEL server subscription so there is a transition point of
sorts at RHEL5. At a glance I'm guessing this added several items
which include clustering and GFS, load balancing, and some
virtualization bits.

Another observation that is important is that "comes on the
installation media" doesn't cut it any more with the release of RHEL6
since half of RHEL6 isn't distributed on media due to its size growing
so dramatically but simply adding the optional channel to what RHEL6
media contains seems to me to include what previously would have been
distributed via the media with the possible exception of some or all
of the Add-On channels which also may have been included on RHEL5
media.

So one question I have is whether it is worth the effort to go back
beyond RHEL5 when looking at this now? Since Red Hat changes this up
every release I doubt EPEL should be bound forever by whatever Red Hat
did in 2004. Where do we want to draw the baseline now?

John

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

Bryan J Smith 06-23-2012 04:52 PM

Overlap policy v20120615
 
Anyone with a RHN Satellite Server can do the entite media history from the Kickstartable Trees in 5 minutes. I.e., I've done it many times over the years, even recently off-list to many.


What I've heard is that some here will only accept a specific, actual statement from Red Hat on its own entitlement history. So doing such, which I've also done, is moot.* I.e., we continue to have a lot of interpretation.




On Jun 23, 2012 12:30 PM, "inode0" <inode0@gmail.com> wrote:
On Fri, Jun 15, 2012 at 5:14 PM, Toshio Kuratomi <a.badger@gmail.com> wrote:

> If you can list for us what actual channels are the equivalent of the old

> AS/AP then we have something else that we can try to use to define logically

> which channels should not be overlapped with. *If you've found this

> information somewhere then giving it to us will be a valuable addition to

> the conversation. *Otherwise, we'll have to continue to assume that there

> isn't an actual understanding of what that is and we'll have to continue to

> try to define it ourselves with a somewhat arbitrary division.



I am willing to do some work here to attempt to sort this out since I

think having a clear policy that EPEL users understand is worth the

bother. I have media going back to RHEL3 and can sort through what

came on it, which I think is a fair definition of what is part of

"RHEL" proper prior to the release of RHEL6.



I do want to observe that there was a media change in RHEL5 which

added some things to the media which required entitlements that go

beyond a RHEL server subscription so there is a transition point of

sorts at RHEL5. At a glance I'm guessing this added several items

which include clustering and GFS, load balancing, and some

virtualization bits.



Another observation that is important is that "comes on the

installation media" doesn't cut it any more with the release of RHEL6

since half of RHEL6 isn't distributed on media due to its size growing

so dramatically but simply adding the optional channel to what RHEL6

media contains seems to me to include what previously would have been

distributed via the media with the possible exception of some or all

of the Add-On channels which also may have been included on RHEL5

media.



So one question I have is whether it is worth the effort to go back

beyond RHEL5 when looking at this now? Since Red Hat changes this up

every release I doubt EPEL should be bound forever by whatever Red Hat

did in 2004. Where do we want to draw the baseline now?



John



_______________________________________________

epel-devel-list mailing list

epel-devel-list@redhat.com

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


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

inode0 06-23-2012 05:01 PM

Overlap policy v20120615
 
On Sat, Jun 23, 2012 at 11:52 AM, Bryan J Smith <b.j.smith@ieee.org> wrote:
> Anyone with a RHN Satellite Server can do the entite media history from the
> Kickstartable Trees in 5 minutes. I.e., I've done it many times over the
> years, even recently off-list to many.

Well, if you would like to tell us which packages based on some logic
we have access to replicate are part of what you define to be RHEL
that would be excellent. Saying you can do it in 5 minutes but not
doing it doesn't help anyone.

> What I've heard is that some here will only accept a specific, actual
> statement from Red Hat on its own entitlement history. So doing such, which
> I've also done, is moot.* I.e., we continue to have a lot of interpretation.

I haven't heard anyone here say that. From my perspective there just
needs to be some reasonable logic in where the line is drawn that EPEL
users can understand.

John

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

Bryan J Smith 06-23-2012 05:22 PM

Overlap policy v20120615
 
On Sat, Jun 23, 2012 at 1:01 PM, inode0 <inode0@gmail.com> wrote:
> ... based on some logic we have access to replicate are part of what
> you define to be RHEL that would be excellent ...

What I and others define with my customers as RHEL has been repeated
viewed by many as unacceptable and/or non-authoritative. I.e., it's
why I stated prior ...

"What I've heard is that some here will only accept a specific, actual
statement from Red Hat on its own entitlement history. So doing such,
which I've also done, is moot.
I.e., we continue to have a lot of interpretation."

That drove why I said I've not only done it (many times in the past,
and most recently last week), but any effort won't be accepted,
because it's not from Red Hat, and not specifically laid out as people
want it on a public page.

It also re-affirmed why I only post technical specifics off-list to
select people. This is not only because my work would be trashed
on-list (some has been trashed enough off-list), but a few people may
make it ... oh how can I say this ... "difficult."

E.g., several people have me utterly confused for others inside of Red
Hat, who I am not. I also don't want anything I say to be taken as
policy, and go out-of-my-way to state historical information or
technical issues, without defining policy.

So I continue to work with people off-list. I hope some results occur soon.

> Saying you can do it in 5 minutes but not doing it doesn't help anyone.

I say many things here that cause people to "roll their eyes," many
because people don't follow what I'm saying at all. If you are
familiar with Red Hat Standard Operating Environment (SOE), like most
major Red Hat accounts, they make sense. I think I used the term
"Common Knowledge" prior. I should refine it to say "SOE Common
Knowledge."

E.g., based on my making the comment ...

"Anyone with a RHN Satellite Server can do the entite media history from the
Kickstartable Trees in 5 minutes"

If you have SOE Common Knowledge, you'd immediately hit those
Kickstart Trees (e.g., /var/satellite/rhn/kickstart). You can see the
channels, the comps.xml and groupings, etc... as the media. And since
it's RHN Satellite, you have the full history, right there,
immediately available, for every channel you've downloaded.

I hope this explains my prior, "common knowledge" statement as well. ;)

If you're a longstanding enterprise, you likely have not only all the
way back to at least RHEL4, if not RHEL3, but likely Extended Update
Support (EUS) as well. In fact, EUS is another, historical
consideration.

SIDE NOTE: From a 100% technical standpoint, if you want to avoid
breakage, avoiding anything also cut for EUS is ideal. This means all
of the AS/AP lineage, including RHEL6's HA, LB, RS (GFS2) plus
Scalable File System (XFS). Why would we want to do that?

GFS2 and XFS are userspace with kernel dependencies. XFS in
particular had a key, kernel-userspace change that required a
userspace change. It's one thing for someone to pull userspace from
an EL Rebuild or upstream and get breakage, they intentionally did it.
But it's another to see it in EPEL, or in the best case, get a
dependency issue as a result.

All I can point to is both historical lineage and technical specifics.
But until something comes directly from Red Hat, on a redhat.com page
and is public, I know most will not be satisfied. Hence why my
efforts have been focused on getting that, and to the specifics I've
seen stated here, to help others make policy.

> I haven't heard anyone here say that. From my perspective there just
> needs to be some reasonable logic in where the line is drawn that EPEL
> users can understand.

I've provided it and it's not enough for some. I've accepted that and
am working with others to see if there can be a very, very specific
document released. I don't want to say more as it's not my place, and
I continue to "stick my neck out" (which clearly a couple people want
to chop off) trying to get people what they want.

I make *0* policy. I only try to point to things that many people
either don't understand, don't believe or otherwise feel is not
authoritative enough. Again, I've accepted that, and am doing my best
to get something more authoritative. From there, I'll let people
decide what they want to do.

I now go back to lurking and working on things with people off-list.


--
Bryan J Smith - Professional, Technical Annoyance

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

inode0 06-23-2012 07:55 PM

Overlap policy v20120615
 
On Fri, Jun 15, 2012 at 2:26 PM, Toshio Kuratomi <a.badger@gmail.com> wrote:
> On Fri, Jun 15, 2012 at 12:43:52PM -0500, inode0 wrote:
>>
>> So the build system is os+optional+lb+ha+rs+other stuff I don't recall
>> if I understood previously but EPEL only prohibits shipping packages
>> from os+optional+lb+ha. I'm wondering why the restriction against
>> shipping packages isn't just os+optional here.
>>
> My understanding is that the buildsystem is os+optional+lb+ha which is the
> set of channels that we are saying we won't conflict with. *In my view, that
> part should always remain consistent.

Ok, and that seems to pretty much map to what was included on the
RHEL5 distribution media in the side repos for Cluster,
ClusterStorage, and VT. On the RHEL6 distribution media there are side
repos for HighAvailability (overlaps Cluster in el5), LoadBalancer
(overlaps Cluster in el5), ResilientStorage (overlaps Cluster and
ClusterStorage in el5), and ScalableFileSystem (not distributed on any
media for el5 that I am aware of currently).

> This doesn't address the "How do I tell if a package shipped by Red Hat
> Channel Foo can be added to EPEL?" question.

So from looking at this from the perspective of distribution media I
would say the current exclusion of HA/LB does logically map in spirit
to what was included in Cluster/ClusterStorage in el5. The part that
isn't so logical is allowing ResilientStorage. That seems to be in the
same category as Cluster/ClusterStorage to me since it overlaps with
those packages. Not sure what makes sense with ScalableFileSystem but
protecting against conflicts there as well seems most consistent to me
(that is the XFS userspace stuff).

John

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

Karanbir Singh 06-23-2012 11:30 PM

Overlap policy v20120615
 
Hi Guys,

I'm not involved with the EPEL base itself, but have an interest..

On 06/15/2012 05:43 PM, Kevin Fenzi wrote:
> "EPEL6 will not normally ship packages that are shipped already in the
> following RHEL channels: os, optional, lb, and ha. Any overlapping
> packages must be to provide binary packages on arches not provided by
> RHEL ( following:
> http://fedoraproject.org/wiki/EPEL:Packaging#Limited_Arch_Packages ).
> Additional channels may be added to this list, based on a criteria the
> EPEL sig has yet to decide on."

What is the overall appetite for expanding scope rather than reducing
scope ? i.e could something like this work :

- the base repo can only contain stuff that isnt in 'os', 'optional',
'lb' and 'ha'. For existing packages moved into those channels post-
point 0 release, the responsibility to notify epel should fall on the
@redhat.com maintainer.

- a secondary repo, can then contain anything that meets the license
terms of Fedora acceptance - i.e be open source and all that. This paves
the way for a newer mysql or an alternate postfix build to then come
into 'community' hands.

nutshell: rather than find ways to do less, and create more barriers -
find a way to do more and have fewer barriers.

--
Karanbir Singh
+44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh
ICQ: 2522219 | Yahoo IM: z00dax | Gtalk: z00dax
GnuPG Key : http://www.karan.org/publickey.asc

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

inode0 06-24-2012 02:32 AM

Overlap policy v20120615
 
On Sat, Jun 23, 2012 at 2:55 PM, inode0 <inode0@gmail.com> wrote:
> On Fri, Jun 15, 2012 at 2:26 PM, Toshio Kuratomi <a.badger@gmail.com> wrote:
>> On Fri, Jun 15, 2012 at 12:43:52PM -0500, inode0 wrote:
>>>
>>> So the build system is os+optional+lb+ha+rs+other stuff I don't recall
>>> if I understood previously but EPEL only prohibits shipping packages
>>> from os+optional+lb+ha. I'm wondering why the restriction against
>>> shipping packages isn't just os+optional here.
>>>
>> My understanding is that the buildsystem is os+optional+lb+ha which is the
>> set of channels that we are saying we won't conflict with. *In my view, that
>> part should always remain consistent.
>
> Ok, and that seems to pretty much map to what was included on the
> RHEL5 distribution media in the side repos for Cluster,
> ClusterStorage, and VT. On the RHEL6 distribution media there are side
> repos for HighAvailability (overlaps Cluster in el5), LoadBalancer
> (overlaps Cluster in el5), ResilientStorage (overlaps Cluster and
> ClusterStorage in el5), and ScalableFileSystem (not distributed on any
> media for el5 that I am aware of currently).
>
>> This doesn't address the "How do I tell if a package shipped by Red Hat
>> Channel Foo can be added to EPEL?" question.
>
> So from looking at this from the perspective of distribution media I
> would say the current exclusion of HA/LB does logically map in spirit
> to what was included in Cluster/ClusterStorage in el5. The part that
> isn't so logical is allowing ResilientStorage. That seems to be in the
> same category as Cluster/ClusterStorage to me since it overlaps with
> those packages. Not sure what makes sense with ScalableFileSystem but
> protecting against conflicts there as well seems most consistent to me
> (that is the XFS userspace stuff).

To make something of a concrete proposal I think it is logical and
easy to understand if we treat HA/LB/RS/SFS in the same manner as they
are all delivered to RHEL customers in the same manner. There are two
obvious choices for what manner they will be treated.

(1) Disallow conflicts with these packages in EPEL. The upside is that
EPEL users know they won't have conflicts with any of these packages
from Red Hat. The downside is that it prevents other packages from
being included in EPEL that have dependencies from this package set.

(2) Allow conflicts with these packages in EPEL. The upside is more
software available in EPEL, both from these channels and from other
packages with dependencies on packages in these channels. The
downside, conflicts for RHEL customers who use these channels
directly. Conflicts can be minimized by careful versioning here.

Some folks will object strongly to both of those options, I believe
they already have objected. So maybe there is a place to meet in the
middle?

(3) Allow packages from these channels into EPEL as dependencies for
other packages using careful versioning to minimize conflicts with
those who subscribe directly to these channels. This will allow more
software into EPEL, reduce dependency failures for those not
subscribing to these channels and minimize conflicts with those who
do.

John

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

Bryan J Smith 06-24-2012 11:13 AM

Overlap policy v20120615
 
inode0 <inode0@gmail.com> wrote:
> (1) Disallow conflicts with these packages in EPEL. The upside is that
> EPEL users know they won't have conflicts with any of these packages
> from Red Hat. The downside is that it prevents other packages from
> being included in EPEL that have dependencies from this package set.

Why would it prevent packages from being included in EPEL?


--
Bryan J Smith - Professional, Technical Annoyance

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

inode0 06-24-2012 03:07 PM

Overlap policy v20120615
 
On Sun, Jun 24, 2012 at 6:13 AM, Bryan J Smith <b.j.smith@ieee.org> wrote:
> inode0 <inode0@gmail.com> wrote:
>> (1) Disallow conflicts with these packages in EPEL. The upside is that
>> EPEL users know they won't have conflicts with any of these packages
>> from Red Hat. The downside is that it prevents other packages from
>> being included in EPEL that have dependencies from this package set.
>
> Why would it prevent packages from being included in EPEL?

Because they either won't build due to unresolved dependencies in the
build system in the cases of RS and SFS or they will build but produce
packages that have unresolved dependencies at install time in the
cases of HA and LB. While we do currently have packages in EPEL in
this latter category I don't think anyone really thinks it is a good
situation and it at the very least contradicts the EPEL note to RHEL6
users that they need to enable the optional channel to satisfy
dependencies.

John

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


All times are GMT. The time now is 09:39 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.