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