Summary/Minutes from today's EPEL meeting (2012-06--08)
kevin at scrye.com
Fri Jun 8 17:02:49 UTC 2012
#fedora-meeting: EPEL (2012-06-08)
Meeting started by nirik at 16:00:52 UTC. The full logs are available at
* init process/agenda (nirik, 16:00:52)
* Broken Deps reports (nirik, 16:04:00)
* nirik to public broken dep script so people can review/hack on it
* nirik to public broken dep script so people can review/hack on it
* RHEL overlap policy (nirik, 16:06:27)
* LINK: http://koji.fedoraproject.org/koji/taginfo?tagID=140 (nirik,
* LINK: http://fpaste.org/xAPF/ (nirik, 16:19:47)
* LINK: http://ftp.redhat.com/redhat/linux/enterprise/6Server/en/*
* proposals on list, further discussion. (nirik, 17:01:04)
* Open Floor (nirik, 17:01:10)
Meeting ended at 17:02:01 UTC.
Action Items, by person
People Present (lines said)
* nirik (91)
* abadger1999 (30)
* maxamillion (27)
* smooge (20)
* zodbot (5)
* dgilmore (5)
* os_ (4)
* cobra-the-joker (4)
* strace (3)
* Jeff_S (1)
* tremble (0)
16:00:52 <nirik> #startmeeting EPEL (2012-06-08)
16:00:52 <zodbot> Meeting started Fri Jun 8 16:00:52 2012 UTC. The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:52 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:52 <nirik> #meetingname epel
16:00:52 <zodbot> The meeting name has been set to 'epel'
16:00:52 <nirik> #topic init process/agenda
16:00:52 <nirik> #chair smooge tremble dgilmore
16:00:52 <nirik> EPEL meeting ping abadger1999 rsc stahnma tremble dgilmore smooge nb maxamillion tremble Jeff_S HackMan
16:00:52 <zodbot> Current chairs: dgilmore nirik smooge tremble
16:00:53 * nirik looks at zodbot.
16:01:06 <smooge> here here here
16:01:24 * maxamillion is here
16:02:19 <dgilmore> hi
16:02:36 <cobra-the-joker> HERE !
16:02:46 * nirik waits a few more for folks to arrive.
16:03:51 <nirik> ok, lets go ahead and dive in then...
16:04:00 <nirik> #topic Broken Deps reports
16:04:19 <nirik> I meant to publish the basic script I had so people could work on it.
16:04:28 <nirik> but I failed. I will do so after the meeting. ;)
16:05:14 <nirik> Basically I have a script that works for epel6, it needs reworking so it could work for epel6+testing and epel5/epel5+testing...
16:05:21 <maxamillion> #info nirik to public broken dep script so people can review/hack on it
16:05:29 <maxamillion> oh wait, that's a chair thing isn't it?
16:05:37 <nirik> if someone can get it all set, I can add it to puppet, etc.
16:05:39 <nirik> maxamillion: yeah.
16:05:41 <nirik> #chair maxamillion
16:05:41 <zodbot> Current chairs: dgilmore maxamillion nirik smooge tremble
16:05:47 <maxamillion> oh goodness
16:05:49 <maxamillion> #info nirik to public broken dep script so people can review/hack on it
16:06:11 <nirik> ok, any questions there? if not, moving on...
16:06:24 * abadger1999 here
16:06:27 <nirik> #topic RHEL overlap policy
16:06:30 * Jeff_S here for one minute then need to run.
16:06:46 <nirik> so, we talked last time about a new policy, and there's been tons of discussion on list.
16:06:58 <nirik> Does anyone have any wording to propose? or further discussion to make on it?
16:07:28 <cobra-the-joker> everyone is sleepy o_0
16:07:38 <smooge> I believe the wording we had last time to cover just stuff under 6 basic is all that is needed
16:07:40 <nirik> yeah, I don't blame them. ;)
16:07:51 <maxamillion> smooge: +1
16:08:41 <nirik> what was that wording? because I want an actual thing we can look at. ;)
16:09:29 * nirik looks
16:10:08 <nirik> "EPEL6 will not ship any packages that have src.rpms under enterprise/6*/en/os/ with an exception for packages not shipped on one arch. Channels under enterprise/6/en/ may request EPEL remove any overlaping packages, and may be queried by EPEL about such overlaps from time to time."
16:10:14 <smooge> <nirik> proposal: EPEL6 will not ship any packages that have src.rpms under enterprise/6*/en/os/ with an exception for packages not shipped on one arch. Channels under enterprise/6/en/ may request EPEL remove any overlaping packages, and may be queried by EPEL about such overlaps from time to time.
16:11:06 <os_> cobra-the-joker, noy me
16:11:09 <os_> cobra-the-joker, not me
16:11:24 <cobra-the-joker> ؟!
16:11:34 <os_> <cobra-the-joker> everyone is sleepy o_0
16:11:38 <smooge> os_, please stay on topic here
16:11:40 <nirik> so, where does that leave the lb and ha channels? we currently use them in our build repo...
16:11:41 <cobra-the-joker> aha
16:11:44 <os_> sorry
16:12:09 <smooge> I think we need to see what gets pulled because of that
16:12:23 <nirik> and it leaves our users kind of unsure which channel is in what state... overlap ok, not ok, changed from ok to not ok... etc
16:13:20 <smooge> nirik, my main questions would be: Does CentOS/SciLin ship those rpms and does a basic subscription get those channels?
16:13:30 <nirik> I'd guess we would need a table on the wiki with that info...
16:13:47 <nirik> I think the answer is no, and yes.
16:13:56 <nirik> but I would have to look to be sure.
16:14:07 <abadger1999> smooge: and, can we use them in our buildsystem.
16:14:25 <nirik> abadger1999: we do currently.
16:14:32 <nirik> http://koji.fedoraproject.org/koji/taginfo?tagID=140
16:14:41 <nirik> server, optional, lb and ha
16:14:47 <abadger1999> yeah. true for those channels. I wasn't sure if smooge's quesetions were more broad.
16:15:29 <nirik> I think it's completely impractical/impossible for us to just enable all channels. Some channels conflict with each other.
16:15:41 <dgilmore> nirik: right
16:15:55 <dgilmore> and some ship different versions of the same thing
16:15:59 <nirik> or at least both provide different versions of the same package.
16:16:06 <smooge> Well if a basic subscription gives those channels then we should go with that. If it doesn't then we shouldn't.
16:16:07 <dgilmore> that could in theory have different sonames etc
16:16:15 * nirik nods.
16:16:20 <maxamillion> smooge: +1
16:16:28 <abadger1999> <nod> Which for me means we should either always allow overlap with those channels or pick one and allow overlap with the other because of the conflict.
16:16:42 <nirik> I have no idea off hand what a basic subscription provides channel wise.
16:16:51 <maxamillion> lemme look
16:16:58 <abadger1999> smooge: I like that position.
16:17:24 <strace> smooge: +1
16:17:29 <nirik> so that would be 'no overlap with channels in a basic subscription' ?
16:18:26 <maxamillion> crap, RHN changed ... I can't find anything
16:18:31 <strace> Actually, how are we defining "basic subscription"? Just RHEL Server or are we defining it as RHEL Desktop?
16:18:33 <smooge> yeah.. the question is how can we get a basic supscription
16:19:00 <nirik> strace: server I assume, thats what we build against.
16:19:06 <strace> ok
16:19:23 <maxamillion> I would think either server or workstation
16:19:33 <maxamillion> probably server though
16:19:47 <nirik> http://fpaste.org/xAPF/
16:20:33 * nirik thinks this is getting too complex again.
16:21:02 <maxamillion> I say we do Server and Optional
16:21:15 <maxamillion> because I think we require Optional anyways don't we?
16:21:21 <nirik> pulling ha and lb would probibly nuke a number of things. I know it will kill heartbeat.
16:22:00 <smooge> Well in that case, could we go with the "we will rebuild with source from channel but at a NVR less than in channel?"
16:22:30 <maxamillion> I feel like that would be a pain to maintain
16:22:34 <nirik> we can, but thats a gigantic pain.
16:22:43 <nirik> I suspect many of the packages we have doing that now are doing it wrong.
16:22:56 <smooge> yeah probably
16:23:24 <smooge> sigh. I propose we end EPEL and let someone else handle this.
16:23:57 <smooge> not too seriously.
16:24:41 <nirik> well, I think any plan we come up with may make some people unhappy, but such is life I fear.
16:25:14 <maxamillion> +1
16:25:37 <maxamillion> can't always satisfy everyone and no matter what, someone's going to complain
16:25:57 <nirik> I guess I am leaning toward: No overlap with os/optional. No overlap with lb or ha (current list, will add channels as requested). Arch exceptions allowed for any overlaps.
16:26:19 <nirik> then when we add a channel on request for no overlaps, we add it to the buildsys and check it then for overlaping.
16:26:27 <abadger1999> How many packages are in ha and lb? How many important ones are?
16:26:29 <nirik> but I don't know if channel owners are going to know to request that.
16:26:47 * nirik looks
16:26:58 <abadger1999> It's possible that we can get those into EPEL.
16:27:36 <nirik> which? all the lb/ha contents?
16:28:01 <maxamillion> we could always say "we don't overlap with anything in http://ftp.redhat.com/redhat/linux/enterprise/6Server/en/ and if you need something there, just pay for it" ... I feel like that would simplify things (but likely upset some folks)
16:28:18 <maxamillion> erm
16:28:20 <maxamillion> http://ftp.redhat.com/redhat/linux/enterprise/6Server/en/*
16:28:26 <maxamillion> asterisk is important ;)
16:29:15 <nirik> maxamillion: that would result in a large drop in epel packages.
16:29:30 <smooge> like over half
16:29:51 <maxamillion> it would make things more simple though ... didn't say it was the greatest suggestion in the world
16:30:16 <abadger1999> maxamillion: Just started browsing and already spotted conflicts there.
16:30:18 <nirik> maxamillion: well, it would make things more simple for end consumers, it would be a nightmare on the rel-eng side.
16:30:18 <maxamillion> I'm just throwing ideas out there and I'm open to others ... certainly not married to any of them
16:30:29 <maxamillion> nirik: oh?
16:30:31 <nirik> yeah, there's not a great answer here.
16:30:35 <abadger1999> CloudForms has a different mod_wsgi package from os
16:30:47 <nirik> and a different puppet from epel
16:30:48 <maxamillion> abadger1999: heh, of course it does
16:31:48 <abadger1999> nirik: yeah, all the lb/ha content
16:33:00 <maxamillion> so is LB/HA considered wide spread enough that we don't want to conflict with it because it would impact a large enough user base that it could be problematic where as other additional subscription channels are a bit more niche or aren't likely candidate deployments for adding in EPEL? (just trying to clarify for myself)
16:33:13 <nirik> since the channels are so different, I don't think we are going to get one size fits all here.
16:33:50 <nirik> maxamillion: yeah, I would agree with that. Base sub allows you to use lb and ha... and they have many popular packages for rhel.
16:34:34 <abadger1999> <nod>
16:34:59 * abadger1999 looks at the list of what's available with base sub again
16:35:14 <nirik> there's some more than I pasted... there's beta ones.
16:35:26 <nirik> but I don't think those should count.
16:36:16 <nirik> lb has 3 packages in it.
16:36:34 <nirik> ha has 158
16:37:00 <abadger1999> Additional channels are: Resilient Storage, Supplementary V2VWin RHN Tools for RHEL, RH Ent Virt Agent, FasTrack (which is a different "type" of channel?)
16:37:20 <nirik> yeah, fastrack is different.
16:39:36 <nirik> so, anyone want to push a proposal? or shall we try and ponder on it more?
16:40:21 <smooge> Well I think status quo works best.
16:40:32 <maxamillion> "status quo" ?
16:40:45 <smooge> ServerOS, LB, HA
16:40:46 <nirik> I guess I will put forth:
16:40:49 <maxamillion> smooge: +1
16:41:15 <abadger1999> nirik: What was "Arch exceptions allowed for any overlaps" above?
16:41:50 * abadger1999 has some wording but would like to incorporate that idea as well.
16:41:58 <nirik> EPEL6 will not conflict with os and optional. Addtionally, it will not conflict with: lb, ha (this list subject to additions). Arch overlaps allowed when there's overlaping.
16:42:05 <nirik> abadger1999: let me get a link, just a sec.
16:42:22 <nirik> http://fedoraproject.org/wiki/EPEL:Packaging#Limited_Arch_Packages
16:42:37 <abadger1999> <nod> k
16:43:13 * nirik notes that inode0 didn't like per channel exceptions as it seemed potentitally confusing to end users, but I'm not sure how to avoid it.
16:43:52 <abadger1999> How about changing your "this list subject to additions) to: (this list subject to additions available to a base subscription where the channels do not conflict with each other, os, or optional)
16:44:44 <nirik> hum, that reads more confusing to me. what does that get us?
16:44:56 * abadger1999 works on the language some
16:45:04 <abadger1999> it gets us a better set of expectations.
16:45:54 <nirik> I see that ha and rs have overlapping packages...
16:45:57 <smooge> does "Overlaps are allowed in arches that do not ship packages in those channels." work better for the second sentence?
16:46:07 <nirik> at least from a quick glance, cluster-glue is shipped in both
16:46:10 <abadger1999> rather than Oh, someone asked that we add this random channel so we should add it and cause disruption to users, it limits the set of channels that could potentially be added.
16:46:21 <nirik> ah, I see...
16:46:38 <nirik> so if we got some other channel telling us not to overlap, we could say sorry/
16:47:56 <abadger1999> yeah.
16:48:16 * nirik doesn't want to cause problems for other channels... you would think they would have a good reason for asking us not to overlap.
16:50:22 <abadger1999> EPEL6 will not conflict with os, optional and certain channels available to a Base Subscription. Currently, those channels are lb and ha but other base subscription channels may be added if they do not conflict with os and optional. Overlaps are allowed to resolve packages missing on a specific arch according to [link].
16:51:06 <abadger1999> that doesn't quite capture things like conflict between ha and rs... hmmm...
16:51:12 <nirik> yeah.
16:51:18 <nirik> I think we need to be more generic.
16:52:00 <smooge> EPEL6 will not conflict with os, optional and certain channels available to a Base Subscription. People who have a problem with this are to see Dennis Gilmore in Blind Dark Alley.
16:52:40 <nirik> EPEL6 will not conflict with os, optional and specific other RHEL channels. Currently those are lb and ha. Other channels may be added on a case by case basis. Overlaps are allowed to resolve packages missing on specific arches according to <link>
16:52:47 <nirik> smooge: +1
16:53:33 <abadger1999> So... od we all agree on the idea of limiting additional channels to (1) no conflicts with the channels already in the buildroot. (2) available to a base subscription?
16:53:36 <abadger1999> *do
16:53:46 <smooge> I do
16:53:48 <nirik> dgilmore: you've been trying to talk with channel owners? How possible is it to find out who owns a channel and communicate with them about this?
16:54:16 <dgilmore> nirik: so far ive not gotten very far
16:54:16 <nirik> abadger1999: I'm not sure about the base subscription thing...
16:54:50 <nirik> I guess the idea is that people with more niche subscriptions would know better how to deal with conflicts/overlaps?
16:55:44 <nirik> but I can think of cases where channel foo ships package bar thats also in epel, and a different version and it's causing them support problems with people overlaping and they ask us to remove bar...
16:56:19 * nirik notes we are coming up on an hour now.
16:56:31 <abadger1999> I was thinking more of the "can contributors still build and run the packages" aspect.
16:56:58 <abadger1999> a base subscription seems like a reasonable line to draw there.
16:57:19 <nirik> yeah, true.
16:57:42 <abadger1999> that said, I feel no conflicts is a blocker for me.
16:57:52 <nirik> yeah.
16:58:02 <abadger1999> base subscription would be very nice, but I could live without it.
16:58:09 <nirik> for example the cluster-glue in ha and rs is the exact same version... does that mean they keep in sync? no idea.
16:58:38 <abadger1999> yeah.
16:59:52 <nirik> so, where shall we go here? proposals on list? more thoughts? different meeting time? ;)
17:00:10 <smooge> I think this time as good as it gets at the moment
17:00:22 <smooge> proposals on list with vote next week
17:00:57 <nirik> ok.
17:01:04 <nirik> #info proposals on list, further discussion.
17:01:10 <nirik> #topic Open Floor
17:01:15 <nirik> anything for open floor real quick?
17:01:50 <nirik> ok, will close out in a minute then.
17:01:53 <nirik> thanks for coming everyone.
17:02:01 <nirik> #endmeeting
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 836 bytes
Desc: not available
More information about the epel-devel-list