19:30:00 <nirik> #startmeeting EPEL (2011-06-20)
19:30:00 <zodbot> Meeting started Mon Jun 20 19:30:00 2011 UTC.  The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:30:00 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
19:30:01 <nirik> #meetingname 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> The meeting name has been set to 'epel'
19:30:01 <zodbot> Current chairs: nirik smooge tremble
19:30:10 <nb> sorry can't be here
19:30:16 * abadger1999 here
19:30:40 <nirik> nb: but... aren't you already here?
19:30:42 <smooge> hello my name is Stephen
19:30:49 <nb> well, have doc appt in 15 mins
19:30:57 <nirik> hey smooge.
19:30:59 * jness here
19:31:01 <nirik> nb: no worries. ;)
19:31:37 <nirik> I didn't have too much today either... I figured we could discuss the mysql forks issue from the list.
19:31:42 <nirik> and anything else folks would like to.
19:31:49 <rsc> Around.
19:32:19 <rsc> what's the issue exactly?
19:33:40 <nirik> #topic Forked versions
19:34:04 <nirik> the issue is someone would like to bring Percona MySQL and MariaDB into epel
19:34:12 <nirik> they are forks of mysql
19:34:50 <nirik> on the surface it would be a 'no, this conflicts with base rhel'
19:35:20 <nirik> but if we allow compat packages to do that, aren't they just another version of a compat package?
19:36:05 <nirik> so, back to the same old question there.
19:36:35 <smooge> yeah.. this one is actually trickier as they are meant to be dropin replacements... and hte only fix I can see is a Conflicts
19:37:23 <nirik> yeah.
19:37:25 <rsc> oh, that's same like my postfix26?
19:37:52 <nirik> one bad thing here is what if a user does a 'yum install /usr/sbin/mysqld' ? what do they get? do they get what they expect?
19:37:58 <nirik> rsc: yeah, in some ways... ;)
19:38:19 <nirik> I think the confusion piles up. ;(
19:39:21 <nirik> anyhow, just thought I would bring it up here.
19:39:22 <smooge> nirik, what happens when one has a conflict in regular fedora
19:39:45 <nirik> you are supposed to work very hard to avoid it. ;)
19:40:19 <smooge> yeah I have 20 packages avoided it by not using it at all :)
19:41:07 <nirik> well, those should all be fixed. A non explicit conflicts is MUST not.
19:41:23 <nirik> There are some cases of explicit conflicts in fedora tho.
19:41:41 <nirik> like fedora-bookmarks and astronomy-bookmarks.
19:41:55 * abadger1999 notes FPC reaffirmed that avoiding Conflicts: is a good thing for Fedora.
19:42:11 <abadger1999> I'm not sure if alternatives is approriate here or not.
19:42:48 <nirik> I suppose it could be, but would also likely be hard to get the maintainer in rhel to support it.
19:42:49 <abadger1999> The packages are drop in replacements but
19:43:02 <abadger1999> they're not backwards compatible
19:43:20 <abadger1999> ie: if I use XTRADB in percona; then I can't go back to vanilla mysql.
19:43:49 <abadger1999> b/c the on-disk format won't be recognized.
19:43:52 <nirik> yeah.
19:44:56 <nirik> Ideally these would be in a different repo entirely... 'epel-danger' or something.
19:44:57 <abadger1999> For EPEL.. I'm thinking it's a question of whether we want to define some sort of "leaf package" and whether we want to let packages Conflict with those leaf packages.
19:44:58 <smooge> are these packages in Fedora?
19:45:00 <nirik> but thats more overhead
19:45:53 <nirik> smooge: not that I see yet.
19:45:57 <abadger1999> where leaf package isn't the normal definition.... ie: mysql lbs would be deps of other packages here, but those are compatible, so they don't play into the euation.
19:46:08 <smooge> so the first process will be a Fedora package review correct?
19:46:14 <nirik> yeah.
19:46:15 <abadger1999> yep.
19:46:23 <smooge> my guess will be that to meet that they are going to need a bunch of changes anyway
19:46:39 <nirik> yeah, likely so...
19:46:43 <abadger1999> and if alternatives were decides as the way to go... that should be done in Fedora packaging before taking it to the EPEL/RHEL mix.
19:46:48 <smooge> like --exec-prefix=maria or some such thing
19:47:20 <abadger1999> <nod>  -- unless we allow the Conflict in Fedora packaging.
19:47:24 <nirik> renaming things to parallel install would be fine, but the problem then is that other packages require: mysql, and wouldn't know that this package could provide that.
19:47:56 <smooge> well they don't really provide mysql.. since the formats aren't 1:1 compatible
19:48:10 <abadger1999> supposedly, they'd provide a superset of mysql.
19:48:30 <abadger1999> so they would provide mysl.. but mysql wouldn't provide mariadb...
19:48:34 <smooge> yeah.. but if you had a mariadb used.. then going to mysql won't work
19:48:39 <abadger1999> yep.
19:48:49 <smooge> ok so we are on the samer page
19:49:07 <nirik> yeah, so I guess we say: get this reviewed and see what solution comes out of that?
19:50:35 <nirik> anyhow, anything else on this?
19:51:32 <smooge> yeah. we then look at epel-leaf or something
19:51:55 <smooge> and let dgilmore and abadger1999 duke it out on a football field with rotten apples or something
19:51:59 <nirik> #topic Open Floor
19:52:04 <kalev> I have something to discuss if you don't mind
19:52:13 <nirik> kalev: sure, go for it.
19:52:20 <kalev> could you guys come up with an answer to Volker Fröhlich's question about EPEL package versioning when the RHEL package is missing on one arch and people want to build a matching package for EPEL?
19:52:24 <kalev> http://www.redhat.com/archives/epel-devel-list/2011-May/msg00082.html
19:52:46 <nirik> kalev: I thought we already did...
19:53:16 * nirik could be wrong
19:53:35 <nirik> I think we should keep epel the same or lower from the rhel versions of packages we are handling this way.
19:53:49 <kalev> in his last mail he asked 'So what shall I do?', so I guess it's not all clear
19:53:53 <nirik> otherwise rhel folks may be upgraded to the epel version and it may cause issues.
19:54:10 <nirik> yeah, I can reply to that. We should update out package guidelines page on this as well.
19:54:11 <smooge> I think lower number works better but that is just me.
19:55:17 <nirik> yeah, it's hard to know how to decrement it right however.
19:55:19 <nirik> sometimes.
19:55:27 <nirik> and then changelog doesn't match up.
19:56:00 * stahnma late as usual
19:56:12 <nirik> hey stahnma
19:56:31 <nirik> if someone has an idea for how we could do lower than rhel version sanely, I'd be for it.
19:56:52 <dgilmore> smooge: didnt you hear
19:56:58 <dgilmore> smooge: im the king of tacking
19:57:06 <smooge> I read that
19:57:24 * dgilmore will have to read back
19:58:11 <nirik> basically the current question is:
19:58:48 <nirik> For those packages that are not available in all arches that we agreed epel can ship, how should we handle versioning. Same exact version as rhel? lower somehow? doesn't matter?
19:59:06 <dgilmore> nirik: i thought we aggreed to use the rhel sources
19:59:12 <rsc> (aside: I put my package with the same version as in RHEL into EPEL)
19:59:12 <dgilmore> and add a 0. to the version
19:59:26 <rsc> dgilmore: did we? Nobody yelled, when I told what I'm going to do...
19:59:43 <dgilmore> rsc: people are not always watching to yell
19:59:53 <dgilmore> but yes that was my understanding
19:59:54 <nirik> dgilmore: so, changelogs won't match up, right?
20:00:15 <dgilmore> just to make sure that where there is the rhel version people install the rhel build and not our build
20:00:28 <dgilmore> since our build is not supported by Red Hat support
20:00:50 <dgilmore> nirik: add a changelong saying adding 0. to make lower then rhel so we can have on arch foo
20:00:51 * nirik had a task to find/list all these packages, but hasn't gotten around to it.
20:02:04 <nirik> I seem to recall seeing some that were already pre-release versions...
20:02:35 <nirik> ie, rhel: 1.0-0.1.gitfoo , which would become: epel: 1.0-0.0.1.gitfoo?
20:03:06 <nirik> that still works tho
20:03:46 <kalev> dpkg's versioning includes a magical ~ symbol, so that version X is guaranteed to be higher than X~Y, e.g. libfoo-0.1 is higher than libfoo-0.1~epel_rebuild0
20:03:49 <kalev> that would be perfect here.
20:04:20 * Jeff_S shows up... better late than never?
20:07:07 <nirik> did we agree these packages needed review as well? or just a maintainer willing to maintain them?
20:07:45 <smooge> I would think that if the package had a form in Fedora then it shouldn't need a review
20:07:59 <smooge> but others might want to make sure that they aren't huge diffs in spec files
20:08:16 <nirik> The only thing that could go wrong is if the versioning is messed up.
20:08:29 <nirik> if we don't want to change things from rhel, the review couldn't change anything anyhow.
20:09:31 <abadger1999> nirik: Your point about not changing makes sense.
20:10:25 <abadger1999> The only other reason for review I could see is if somethings should not go in.
20:10:26 * nirik is editing the wiki.
20:10:42 <abadger1999> but that could be done by epel releng or something.
20:11:25 <nirik> such as? sun java or something?
20:11:36 <nirik> https://fedoraproject.org/wiki/EPEL:Packaging#Limited_Arch_Packages
20:11:48 <nirik> take a look at that and see if it matches up with what everyone would like?
20:12:00 <abadger1999> or someone making a package that already is available on all arches in rhel.
20:12:46 <kalev> > 3. Change the version of the package to have a leading 0. /.../
20:12:50 <kalev> that should read release
20:13:33 <nirik> yeah, sorry... added one about licensing and dist rules.
20:14:12 <nirik> ok, updated.
20:16:21 <nirik> look ok?
20:20:11 * nirik waits for screaming
20:21:47 <smooge> is reading
20:24:06 <smooge> looks good to me
20:26:02 <nirik> ok, if no one screams, I guess we adjuorn?
20:27:57 <nirik> ok, I will close out the meeting in a minute if nothing more...
20:28:53 <kalev> thanks for taking a look at that
20:29:48 <nirik> kalev: no problem. Thanks for bringing it up.
20:29:53 <nirik> Thanks for coming everyone!
20:29:55 <nirik> #endmeeting