19:30:01 <nirik> #startmeeting EPEL (2011-06-13)
19:30:01 <zodbot> Meeting started Mon Jun 13 19:30:01 2011 UTC.  The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:30:01 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
19:30:01 <nirik> #meetingname epel
19:30:01 <zodbot> The meeting name has been set to 'epel'
19:30:01 <nirik> #topic init process/agenda
19:30:01 <nirik> #chair smooge tremble
19:30:01 <nirik> EPEL meeting ping abadger1999 rsc stahnma tremble dgilmore smooge nb maxamillion tremble Jeff_S
19:30:01 <zodbot> Current chairs: nirik smooge tremble
19:30:33 <nirik> any folks around for an epel meeting today?
19:30:43 * abadger1999 here
19:31:07 * nb here
19:31:28 * jness here
19:31:53 <nirik> abadger1999: added some agenda items...
19:32:07 <abadger1999> <nod>
19:32:07 <nirik> I didn't have any others... anyone else have topics for us to discuss later in the meeting?
19:33:07 * nirik waits another minute for folks to wander in
19:34:42 <nirik> ok, lets go ahead.
19:34:55 <nirik> #topic 2011-06-13 - Conflicts Guidelines
19:35:30 <nirik> so, this topic came up again... refering to newer versions of packages...
19:35:37 <nirik> in this case zabbix18
19:37:01 <nirik> I think it's possible we are covered here by the compat packages conflict.
19:37:51 <abadger1999> <nod>
19:37:54 <nirik> http://fedoraproject.org/wiki/Packaging:Conflicts#Compat_Package_Conflicts
19:38:05 <abadger1999> after looking at it, it seems to fit.  We just have to think of it as forward compat.
19:38:07 <nirik> and this is what rhel did with their newer packages in rhel5.
19:39:39 <nirik> so, should we add a note about this on the epel guidelines page?
19:39:44 <nirik> or just refer people to this one for this case?
19:40:17 <abadger1999> Yeah, I'll put a note in.
19:40:23 <abadger1999> Since it comes up from time to time.
19:41:34 <nirik> ok, thanks.
19:41:36 <nirik> anything more on this?
19:41:37 <abadger1999> #action abadger1999 to note on EPEL guidelines page that the compat package case allows conflicts for forwards compat
19:41:45 <abadger1999> That's all from me.
19:42:06 <nirik> #topic 2011-06-13 - Python26 subpackages vs separate packages
19:42:28 <nirik> I know doing multiple versions from one spec was talked about a while back, but then didn't seem to be prefered.
19:42:32 <nirik> has something changed?
19:42:48 <abadger1999> I think the two things were: 1) didn't get documented
19:42:58 <abadger1999> 2) dmalcolm has a page that advises the opposite.
19:43:11 <derks> I added "__multiple_python_os_install_post" to the python26, allowing both python and python26 (subpackages) in one spec to be properly byte compiled
19:43:33 <abadger1999> http://fedoraproject.org/wiki/Python26#Packaging_Guidelines_for_EPEL5
19:43:34 <derks> rather than the previous __python26_os_install_post
19:43:46 <nirik> well, the issues I see with doing them both in one package:
19:44:17 <nirik> 1) if the primary maintainer and the 26 maintainer are different people and don't want to work together
19:44:34 <nirik> 2) bug filing may be anoying if people can't find the 26 package...
19:45:22 <derks> There are already packages outside of python26 that would be affected by [2]
19:45:37 <nirik> sure.
19:45:52 * nirik is mostly playing devils advocate... I don't know that I care which way we do it.
19:46:13 <nirik> also, note that if we moved the existing ones it would be a flurry of dead packaging and merging into the base package, etc.
19:46:37 <derks> as for [1] ... I think that is valid... if the python-xxx maintainer doesn't care about python26, then someone else can maintain it... but it should be atleast offered/requested of them to add it
19:46:42 <nirik> 3) no reviews for new 2.6 packages could lead to problems... but then any change can lead to problems. ;)
19:46:55 <abadger1999> 3) People who want python26 tend to want the latest module -- which simply adding a subpackage to the existing module would not bring
19:47:35 <abadger1999> 4) When an update builds on python26 but not python24 (or vice versa) we're stuck not being able to update the package until the incompatibility is fixed.
19:47:39 <nirik> yeah, true there too.
19:47:48 <derks> true
19:48:10 <nirik> does this discussion also apply to python3 in fedora?
19:48:41 <abadger1999> It does
19:49:09 <abadger1999> In Fedora, I was against subpackages and dmalcolm was for and in the end we went with subpackages...
19:49:29 <abadger1999> But I've regretted it since (being stuck unable to build packages b/c of incompatibility of the code with python3)
19:49:43 <abadger1999> #3 doesn't apply as much
19:50:11 <abadger1999> Since Fedora moves quicker than RHEL, we're able to upgrade both the python2 and python3 modules at a similar pace.
19:50:19 <nirik> well, simply based on inertia, just sticking with seperate packages in epel would be the easy course. ;)
19:51:09 <abadger1999> <nod>
19:51:18 <abadger1999> I'd be for that :-)
19:51:32 <abadger1999> Just want to make sure I can document it and make it so.
19:51:40 * nirik is fine with that.
19:51:44 <fedora_richie__> :)
19:51:48 <abadger1999> Excellent
19:51:51 <nirik> derks: you have a bunch of these I think... thoughts?
19:52:23 <derks> I think it is real convenient to just be able to build both from one spec
19:52:27 <derks> package reviews are a pain
19:53:01 <derks> ... so I'd say, if the python26 package started to hold up the base python package... or vice versa, then at that time break of the python26 package into its own
19:53:42 <abadger1999> I favor all or nothing because of end user confusion
19:53:54 <nirik> yeah.
19:54:03 <abadger1999> reporting bugz in bugzilla is easy if you know to either go to python26-module OR python-mnodule
19:54:09 <derks> there are a lot of small python libraries that aren't under active -incompatible- development that keeping python and python26 in line isn't hard
19:54:27 <abadger1999> Similarly fedpkg clone python-module OR fedpkg clone python26-module bodhi [...] etc
19:55:05 <abadger1999> all that gets harder when users can't count on one method or the other consistently.
19:55:51 <nirik> yeah.
19:56:07 <derks> abadger1999, I hear you there.  Though, I think if we had an easy lookup to determine the base package that provides a subpackage it could be less confusing
19:56:20 <derks> like... for zodbot, or in pkgdb
19:56:39 * abadger1999 can see derks' point about some modules being not under active development, though.
19:56:43 <derks> "what's the base package for python26-sqlalchemy"... etc
19:57:04 <nirik> well, repoquery can do it, but it confuses users
19:57:18 <derks> nirik, right.. i'm thinking of say... something that wraps around that
19:57:23 <derks> say in fedpkg
19:57:50 <derks> fedpkg base-pkg python26-xxxxx
19:57:57 <derks> > python-xxxxx
19:58:01 <derks> or something
19:58:39 <derks> all or nothing just bums me out cause i spent a lot of time figuring out __multiple_python_os_install_post...  but I'm with the majority on this one
19:59:27 <nirik> perhaps we revisit it when there's another stack in rhel6?
19:59:42 * derks knows 'alot of time' is probably an over statement
20:01:14 <nirik> I could see us saying: rhel5 does things this way, rhel6 this other way...
20:01:32 <nirik> still confusing, but less so than 'a package can do it either way
20:02:12 <derks> nirik, pretty sure dmalcolm wanted to get python3 into RHEL6 at some point
20:02:19 <nirik> yeah
20:02:20 <derks> just fyi
20:02:53 <nirik> ok, so we stick with seperate packages for now? everyone ok with that?
20:03:27 <derks> nirik, does that mean python26-xxx subpackages are no longer allowed?
20:03:48 <nirik> well, do we have any of those?
20:03:52 <abadger1999> nirik:  status quo is maintainer choice
20:03:55 <derks> i think i might
20:04:03 <nirik> ah, ok... confusing, but ok.
20:04:23 <abadger1999> I've been trying to squash subpackages whenever I see someone propose them but...
20:04:46 <abadger1999> I'm not watching every python module in epel :;-)
20:05:29 <derks> if that's the way we go, its fine... i just need to know
20:05:33 <abadger1999> how about this -- I'll rewrite dmalcolm's suggestions to list the cons of subpakages
20:05:49 <abadger1999> and link the EPEL guidelines to that page
20:06:03 <abadger1999> maintainer choice continues in RHEL5
20:06:20 <abadger1999> RHEL6 we revisit when python3/python27  is added
20:06:32 <nirik> seems fine to me
20:06:46 <derks> abadger1999, that sounds good.  definitely like the idea of making it really clear why *not* to do subpackages
20:07:02 <abadger1999> Cool.
20:07:16 <abadger1999> #action abadger1999 to write up cons on the wiki and link epel guidelines to that.
20:08:00 <nirik> there are some
20:08:02 <nirik> http://fpaste.org/bLvs/
20:08:44 <nirik> anyhow... sounds good.
20:08:48 <nirik> #topic Open Floor
20:08:51 <nirik> anything for open floor?
20:10:10 * stahnma is late
20:10:11 <stahnma> again
20:10:12 <stahnma> ;)
20:10:41 <nirik> stahnma: thats ok. Anything for open floor? ;)
20:11:00 <stahnma> I don't think I have anything
20:11:42 <nirik> ok, thanks for coming everyone.
20:11:47 <nirik> #endmeeting