19:30:02 #startmeeting EPEL (2011-06-27) 19:30:02 Meeting started Mon Jun 27 19:30:02 2011 UTC. The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:30:02 Useful Commands: #action #agreed #halp #info #idea #link #topic. 19:30:02 #meetingname epel 19:30:02 #topic init process/agenda 19:30:02 #chair smooge tremble 19:30:02 EPEL meeting ping abadger1999 rsc stahnma tremble dgilmore smooge nb maxamillion tremble Jeff_S HackMan 19:30:02 The meeting name has been set to 'epel' 19:30:02 Current chairs: nirik smooge tremble 19:30:18 * rsc is around 19:30:22 * nb 19:30:39 hiya 19:32:13 * nirik waits a minute or two more for folks to wander in. 19:34:43 HackMan: you around? 19:34:54 any other folks have topics we should discuss today? 19:37:15 * nirik listens to crickets 19:37:22 I'm here 19:37:43 * derks has no topics... just lurking 19:38:06 the only topic I have, is off-topic and is that RHEL Optional repo just sucks :( 19:38:40 nirik here 19:38:52 cool. 19:38:57 #topic Should Percona SQL and/or MariaDB be part of the EPEL repo? 19:39:05 HackMan: can you give us background on this issue? 19:39:45 Oracle's MySQL does not accept community patches and will not accept them in the future 19:40:06 I and a lot of other users need at least the Google patches for MySQL 19:40:24 Statistics and better InnoDB 19:40:52 these are packaged by two other Projects: Percona's MySQL and MariaDB 19:41:05 both Percona and MariaDB are drop in replacements for MySQL 19:41:38 Percona uses the same code as Oracle's mysql, simply adding the Google patches and XtraDB storage Engine 19:41:51 MariaDB is a complete fork of Oracle's MySQL 19:42:09 HackMan: Question: do you know what Fedora intends to do? keep shipping mysql? or switch? or ? 19:42:39 for whats its worth I'm the upstream packager for drizzle, and will be adding drizzle package in the near future... 19:42:58 I wish to add both or at least one of the packages to the EPEL repo and I want to maintain the packages. 19:43:05 though.. that is not exactly a replacement for what mysql is at this stage 19:43:41 derks: drizzle is another mysql fork? 19:43:47 derks drizzel doesn't actually use /etc/my.cnf and it doesn't replace libmysqlclient 19:43:51 nirik, yes 19:44:19 HackMan, correct... though it does speak the mysql protocol via the mysql_protocol plugin (and listens on 3306) 19:44:29 we did discuss this a bit in a previous meeting. 19:44:31 * nirik looks back. 19:44:35 the mysql_protocol plugin is disabled by default in my packages obviously 19:45:01 drizzle is by no means a replacement for shipping mysql... i just thought I'd throw it in the pot 19:45:27 so, my question is will it be possible to include Percona or MariaDB in EPEL? 19:45:33 from the history of packages getting entered into EPEL, we don't usually add in stuff that conflicts. So how can we get them not to conflict 19:45:39 HackMan: so I think the next step for you is to submit reviews. We agreed that "forward compat" conflicts would be acceptable for epel. 19:46:27 or at least I thought we did. 19:46:37 smooge , nirik can you please agree ? :) 19:46:57 * Jeff_S is for including them 19:47:10 dgilmore, ping 19:47:11 http://meetbot.fedoraproject.org/teams/epel/epel.2011-06-13-19.30.log.html#l-19 19:47:24 I'm happy (ok, I lie) to revisit. 19:47:33 smooge: I think dgilmore is on his way to Brazil today 19:47:36 I am arguing from remembering dgilmore's strong objections in the past on this 19:47:55 versus any love of it myself 19:48:04 nirik: "forward compat"? 19:48:28 rsc: so, conflicts have been allowed in the case of compat packages... 19:48:32 rsc Provides: mysql Conflicts: mysql 19:49:00 in cases when say db3-devel conflicted with db-devel and it was too hard to change them. 19:49:11 nirik: oh, we allow overlaps with base packages? 19:49:13 so, we were saying that php53 could conflict with php since it's a newer one. 19:49:28 well, carefull there. What do you mean by 'overlap' ? 19:50:09 the name of the packages will be different, but since they have conflicting files the new package should have the Conflicts with the old one 19:50:31 and should also provide the old one, since there would be a lot of software that depends on mysql 19:50:55 HackMan: well, that we would need to be very very carefull with, IMHO. 19:51:06 if someone does 'yum install mysql' they should NOT get an epel package. 19:51:33 * stahnma is here now 19:51:36 late ...again 19:51:57 nirik I agree, I would need some time of testing to make sure there are no such issues 19:52:00 so, I'd like to have input from dgilmore on this for sure. I thought he was ok with forward compat, but we should find out. 19:52:02 has this been attempted in Fedora already? I know I brought it up a while back but never went anywhere with it 19:52:11 Ok in any case, getting the packages into a fedora release looks like the needed step so that would give dgilmore time to be at a meeting. 19:52:13 HackMan: perhaps a 'Provides: mysql = oldversion' 19:52:29 Jeff_S: which? the mysql forks? 19:52:40 nirik: correct 19:53:23 nirik yup, but as I said, it will need some experimentation just to make sure its working as expected 19:53:31 * stahnma in favor of having those db packages 19:53:39 sure. 19:53:52 nirik: well...that comes down to my postfix26 thing ;) 19:54:38 rsc: indeed it does. 19:54:39 rsc I'm half way done with porting of the debian separation patch for the postfix28 packages 19:54:48 so, how about this: 19:55:00 would folks interested in this write up an actual proposal in the wiki? 19:55:07 and we can revisit at the next meeting? 19:55:12 HackMan: sorry, no option for me. I just want RHEL 6 postfix in RHEL 5 ;) 19:55:25 nirik: that sounds good 19:55:28 I think it needs to address the requirement that installing the base package never installs from epel, and such. 19:56:03 nirik a package proposal in the bugzilla or something else ? 19:56:24 wiki? 19:56:36 HackMan: no, a proposal on this 'forward compat' conflicts. 19:56:45 what a maintainer needs to do/not do. 19:57:13 nirik ok, and add that to the agenda for the next weeks meeting ? 19:58:18 sure. Note that next monday is a holiday in the US... so likely no meeting... 19:58:24 we could just discuss on list too. 19:58:25 good point 19:59:03 so, here is what I will do. I'll create a spec file with MariaDB or Percona... and test the installations by adding that packet to a enabled repo 19:59:28 the main idea would be if I install the package, it must not break any already installed packages 19:59:47 if I try to install mysql it should conflict with my package 19:59:55 sounds good. 20:00:00 and if I don't have mysql and run yum install mysql 20:00:06 it should install the base OS mysql 20:00:34 if I cover all of these, then I can write a package review request 20:00:35 ok ? 20:00:38 right. And I think nirik was looking for a written description what do to and not to do technically in the *.spec for a guideline? 20:01:03 Yup, I'll document that, once I know it :) 20:01:07 I think that if he can do those, that would be a good starting point :) 20:01:15 currently it's only in theory in my head :) 20:01:36 well, it works. It is working for my postfix26 already ;) 20:02:02 I can't start today since I'm up for more then 50h but tomorrow I'll start working on this. 20:02:37 rsc: yeah, would be another good one to note... can you make your spec available for HackMan ? 20:03:22 nirik: it is. https://bugzilla.redhat.com/show_bug.cgi?id=694673 - but he needs to compare with the RHEL 6 one where it is based off. 20:03:26 nirik I think I already have it :) rsc the postfix26 packages from CentOS plus ? 20:03:46 no, link above. Don't know what CentOS plus is shipping. 20:04:08 (but I think, I'm missing the Conflicts:) 20:06:03 rsc yup you are 20:06:47 if this package doesn't Conflicts with the original postfix it will conflict during installation, which as far as I remember is against the guidelines 20:07:48 right. 20:07:49 it is. 20:07:58 ok, anything further on this? 20:08:12 no, when I'm ready I'll post to the thread on the list 20:08:29 HackMan: thanks. 20:08:34 #topic Open Floor 20:08:38 anything for open floor? 20:09:00 then if, you agree that the SPEC is ok, I'll write the package review request 20:09:50 sounds good. 20:09:57 HackMan: do you intend to maintain in Fedora as well? 20:10:01 will I need to wait for the next meeting or you can make that decision in the mailing list 20:10:19 nirik if there is demand, thats not a problem for me 20:10:33 cool. 20:10:53 well, if we can get folks to chime in on list we could just figure it out there. 20:11:01 it;'s sometimes hard to get people to respond... 20:11:24 ok, if nothing else will just close out in a minute here. 20:11:31 Currently I keep two CentOS VMs (32 and 64bit) 20:11:39 I'll need to build two more for Fedora 20:11:44 but its not a problem 20:14:37 ok, then we are finished with the meeting ;) 20:15:03 yeah 20:15:05 #endmeeting