16:06:27 <spot> #startmeeting Fedora Packaging Committee
16:06:27 <zodbot> Meeting started Wed Oct 31 16:06:27 2012 UTC.  The chair is spot. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:06:27 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:06:30 <spot> #meetingname fpc
16:06:30 <zodbot> The meeting name has been set to 'fpc'
16:06:35 <spot> #topic Roll Call
16:06:52 * limburgher here
16:06:52 <tibbs> Howdy.
16:06:55 * abadger1999 here
16:07:03 <tibbs> Was going to go vote if we weren't meeting.
16:07:11 <rdieter> here
16:07:29 <limburgher> tibbs:  Dang.  Maybe if we're fast. . .
16:07:30 <abadger1999> tibbs: Early US voting?
16:08:18 <spot> racor, geppetto, SmootherFrOgZ: ping?
16:08:23 <tibbs> Yes, but I can just go afterwards.  I'm off today so it's no big deal.
16:08:42 * geppetto is here
16:09:27 <spot> well, we definitely have quorum
16:09:31 <spot> so lets get started
16:09:40 * racor is here
16:09:47 <spot> #topic Approval of Conflicts - https://fedorahosted.org/fpc/ticket/224
16:10:25 <spot> The situation here is that for the last twenty years or so (not hyperbole) hylafax and mgetty+sendfax have been using the same binary names to do similar (but incompatible) functions
16:10:37 <limburgher> So they implicitly conflict.
16:11:16 * abadger1999 not really for conflicts here
16:11:17 <spot> well, they don't implicitly conflict, hylafax (not yet in fedora) directly conflicts with mgetty-sendfax (in fedora)
16:11:35 <abadger1999> but the *long* history makes getting upstream to agree seem mighty slim.
16:11:51 <spot> Neither side is willing to rename the binaries, especially since the epic history of these two things.
16:12:05 <limburgher> I meant the files conflict, but there's no Conflicts:.
16:12:15 <abadger1999> We could also change our conflict guidelines... there's been other people (adamw being one of the leaders) who have spoken out against our anti-conflicts guidelines
16:12:43 <spot> Given that this is about fax support programs, I think at the very least, we should permit this exception and allow explicit Conflicts here.
16:13:48 <limburgher> I tend to side with spot here, mostly because this is more like the mta case than the language interpreter or library case.
16:14:09 <limburgher> Is there a use case for having both installed?
16:14:16 <abadger1999> err
16:14:23 <rdieter> spot: +1
16:14:28 <abadger1999> if this is like the mta case.. we should be talking alternatives.
16:14:47 <spot> alternatives would apply if they were drop-in replacements for each other
16:14:55 * abadger1999 would be for a change to conflicts guidelines that allows this but would be -1 to an exception.
16:14:55 <limburgher> abadger1999: I was thinking that too.
16:14:58 <spot> all the mta's "emulate" sendmail's commandline flags
16:15:09 <geppetto> spot: +1 for allow with explicit conflicts
16:15:28 <spot> this is a case where the binaries do similar tasks but in incompatible ways
16:15:42 <geppetto> spot: I assume the binaries are not compatible at all?
16:15:49 <limburgher> spot:  Ah.
16:16:06 <spot> i can't really envision a scenario where you'd want two efax mechanisms
16:16:14 <spot> (simultaneously)
16:16:18 <geppetto> spot: I could say the same thing about two MTAs
16:16:22 <abadger1999> spot: yeah.  agreed that htis isn't a case for alternatives.
16:16:45 <rdieter> an alternative (pun!) is to require *both* packages to rename/namespace stuff to avoid conflicts (but that's not really viable, given the history and the odds of upstreams accepting it)
16:16:47 <abadger1999> so just saying that this is *not* like mtas in my mind :-)
16:16:53 <limburgher> rdieter: <headdesk>
16:16:56 <racor> how do other distros handle the situation?
16:16:57 <spot> i'm not opposed to reworking the Conflicts guidelines to permit this, but i don't want this blocked while we try to figure that out.
16:17:08 <abadger1999> rdieter: well -- for other packages, we rename despite upstream :-)
16:17:09 <spot> racor: debian does a conflicts
16:17:11 <limburgher> abadger1999: Gotcha
16:17:28 <abadger1999> I'd say new section to Acceptable use of conflicts
16:17:28 <racor> spot: suse, they also seem to have both ...
16:17:36 <abadger1999> Maybe something like:
16:17:39 <rdieter> abadger1999: really?  what other examples do we have where upstreams refused renaming?
16:17:52 <geppetto> Given the long history I'm ok with an exception … if it's even remotely useful, I'd prefer alternatives (I'm just not sure it is).
16:18:07 <spot> OpenSUSE has explicit Conflicts as well.
16:18:19 <abadger1999> If there's no reason that any user would want to install both versions of the package on a single system, then Conflicts are okay.
16:18:24 <geppetto> I mean this isn't going to come up much, so we aren't going to deal with a lot of exceptions.
16:19:16 <abadger1999> I would even be okay with putting a "Ask FPC to evaluate whether that's the case for your package and list it here" if we don't trust maintainers to evaluate that stringently enough.
16:19:25 <racor> spot: Yeah, you were faster  - they seem to have sendfax split out and let hylafax and sendfax conflict.
16:19:31 <geppetto> abadger1999: Again … as with MTAs, that's not the reason. I thought the big thing was getting as close as possible to having "yum install \*" work?
16:19:39 <abadger1999> rdieter: python-migrate: /usr/bin/sqlalchemy-migrate
16:20:03 <abadger1999> geppetto: if that's the case, then logically, we'd vote no to an exception here.
16:20:17 <abadger1999> geppetto: and yes, that was one of the big rationale in the past.
16:20:21 <spot> abadger1999: i would say "If neither upstream is willing to rename the binaries to resolve the conflict, and the binaries are not viable candidates for alternatives (incompatible runtimes), as long as there are no clear cases for both packages to be installed simultaneously, explicit Conflicts are permitted at the packager's discretion. Both packages must carry Conflicts in this case."
16:20:32 <abadger1999> geppetto: I'm just not sure we want to continue making that a rationale now.
16:20:41 <spot> hell of a runon sentence there, but thats the logic process.
16:20:50 <limburgher> spot: +1
16:20:51 <abadger1999> since so many people want to grant an exception in tis case.
16:21:16 <racor> Provided hylafax is a freestanding suite, I am wondering if hylafax can't be modified to install its binaries into a private "libexec"-like directory?
16:21:25 <geppetto> spot: +1
16:21:30 <abadger1999> spot: I could vote yes for that.
16:21:33 <limburgher> abadger1999:  I once cared more about that rationale than I do now.  I think it was more achieveable when we had fewer packages.
16:21:49 <spot> racor: i think it is less about that and more about the fact that all sorts of apps assume hylafax binaries exist in a hardcoded path. Stupid? Absolutely.
16:22:24 * spot is +1 for his proposal
16:22:55 <racor> spot: which apps? apps ontop of hylafax?
16:23:06 <tibbs> Note that as before I'm not involving myself in this.
16:23:23 <spot> racor: yeah. it is not uncommon for apps to have fax support, which amounts to piping output to the hylafax binary.
16:23:38 <spot> not that i do a lot of faxing (it is 2012, after all).
16:23:59 <racor> spot: ouch, combining this with "conflicts" means introducing chains of conflicts.
16:24:34 <spot> racor: not sure i understand.
16:25:45 <racor> spot: "apps ontop of hylafax" == Requires: hylafax => Pulls in Conflicts: mgetty-sendfax
16:26:01 <spot> racor: yeah. i suppose, but that is very unlikely.
16:26:11 <spot> right now, there are none of those in Fedora.
16:27:27 <limburgher> Unless we get lucky and they all use file requires and use only compatible options.
16:27:28 <spot> Nothing Requires mgetty-sendfax either
16:27:34 <limburgher> Which I dbout.
16:27:40 <limburgher> Which is a lot like doubt.
16:27:44 <spot> so this issue is really hypothetical.
16:27:51 <spot> anyways, i see +3 on my proposal
16:27:57 <abadger1999> =1
16:27:59 <abadger1999> +1
16:28:43 * abadger1999 sees the theoretical problem with chains of conflicts though...
16:28:50 <spot> tibbs is abstaining, so we need racor/rdieter to vote on this.
16:29:02 <rdieter> +1
16:29:20 <limburgher> abadger1999: I seem to recall hitting that on a debian box a decade or so ago. . .once. . .
16:29:22 <abadger1999> We'd probably want to encourage a best practice of patching code to use either.
16:30:06 <racor> libburgher: I recall this issue on suse ca. a decade ago. There were GUIs causing the issues.
16:30:18 <abadger1999> if /usr/bin/sendfax --version|grep Hylafax ; then # one thing ; elif   /usr/bin/sendfax --version|grep mgetty-sendfax # another thing
16:30:19 <spot> we could add some wording here to say that "Be aware, adding explicit Conflicts means that if any other packages depend on your package, you may be creating a chain-of-conflicts that could cause user pain. Please consider this a last resort."
16:30:27 <limburgher> racor:  Mostly games in my case.
16:30:46 <limburgher> spot:  I'm ok with that.
16:31:19 <spot> anyone else like that approach?
16:31:51 <abadger1999> +1 from me
16:32:11 <spot> okay, i see +2 for that addendum
16:32:15 * rdieter is fine with or without the additional warning, +1 i guess
16:32:19 <abadger1999> I don't think it will help dissuade people who want to use this clause but it's not going to hurt.
16:32:56 * abadger1999 wonders if mariadb/perconadb will try to use this.
16:33:37 <spot> abadger1999: i don't think they can, there is at least some semblance of binary compatibility at the runtime
16:34:16 <abadger1999> <nod>  We'[ll cross that bridge when in comes up on devel list :-)
16:34:28 <racor> 0, I am hesitant for 2 reasons: a) I do not want to provide a precent on Conflicts  b) I am not convinced the hylafax conflict can't be solved in different ways (e.g. /usr/libexec/hylafax)
16:34:32 <spot> i think it is far more likely that they'll use alternatives to get this done.
16:35:30 <spot> that's really the only reason that mariadb/perconadb use the same naming, to be a drop-in replacement.
16:35:35 <rdieter> racor: it certainly could be solved that way, *if* there was the time and will to implement it
16:35:55 * spot is +1 on his addendum, so we're at +4 there
16:36:11 <spot> geppetto: i think you're our missing voter on the addendum.
16:36:18 <geppetto> spot: No, I voted +1
16:36:53 <spot> okay, well, that makes +5
16:37:28 <spot> #action Amend Conflicts guidelines to read: ""If neither upstream is willing to rename the binaries to resolve the conflict, and the binaries are not viable candidates for alternatives (incompatible runtimes), as long as there are no clear cases for both packages to be installed simultaneously, explicit Conflicts are permitted at the packager's discretion. Both packages must carry Conflicts in this case. Be aware, adding explicit Conflicts means that if
16:37:28 <spot> any other packages depend on your package, you may be creating a chain-of-conflicts that could cause user pain. Please consider this as a last resort." (+1:5, 0:1, -1:0)
16:38:21 <spot> skipping the bundling tickets... lets look at 228
16:38:31 <spot> #topic Minor change in PHP Guidelines - https://fedorahosted.org/fpc/ticket/228
16:39:04 <tibbs> I really wish this didn't imply that you have to have a different spec for F19+.
16:39:11 <spot> this seems like an EASYFIX, just need to redefine %{pear_metadir}.
16:39:29 <spot> tibbs: i don't think you do, he's just redefined the value of the macro in F19.
16:39:48 <RemiFedora> => %{!?pear_metadir: %global pear_metadir %{pear_phpdir}}
16:39:55 <limburgher> Which means you actually get to have a unified spec if you use it, rather than if you don't.
16:39:58 <abadger1999> This looks like it isn't used in general within a spec file
16:40:12 <abadger1999> So yeah, shouldn't need to change specs for f19+
16:41:10 <rdieter> easyfix, +1
16:41:12 <tibbs> Ah, OK, I was trying to parse what was written in the ticket but I see how it could mean that.
16:41:13 <spot> +1
16:41:15 <limburgher> +1
16:41:23 <geppetto> Doesn't it also need to be added un PECL modules
16:41:32 <tibbs> So +1, but also, can we remove mention of FC5 from that section while we're in there?
16:41:40 <spot> geppetto: if they want to start using %{pear_metadir}, yes.
16:41:46 <spot> tibbs: sure.
16:41:54 <geppetto> might be nice to have one line description saying what goes there.
16:41:56 <geppetto> But, +1
16:42:01 <tibbs> I don't think pecl stuff works the same way in any case.
16:42:25 <abadger1999> +1
16:42:25 <RemiFedora> no, pecl package doesn't use metadata at RPM build time
16:42:36 <racor> Doesn't this change require a versioned requires and a mass rebuild?
16:42:41 <geppetto> RemiFedora: Ok, just saw a copy of all the other macros.
16:43:22 <geppetto> racor: AIUI some stuff can change from using pear_phpdir to pear_metadir
16:43:41 <geppetto> racor: But I might well _not_ understand it :)
16:43:42 <tibbs> I seem to recall a message on the php list about a mass rebuild being needed.
16:43:53 <racor> geppetto: no cross dependencies?
16:44:09 <RemiFedora> tibbs, not a mass rebuild, just a mass FTBFS
16:44:12 <tibbs> WARNING : all pear packages will be FTBFS.
16:45:00 <spot> racor: i believe i misspoke, i don't think the %{pear_metadir} macro was in use before now, things were using %{pear_phpdir} before. remi is adding the %{pear_metadir} macro for all active branches, it is defined to %{pear_phpdir} for everything except /var/lib/pear in F19. This means rawhide needs a rebuild of pear bits for this to take effect.
16:45:04 <spot> i think thats right.
16:45:05 <tibbs> http://lists.fedoraproject.org/pipermail/php-devel/2012-October/000192.html
16:45:12 <racor> RemiFedora: Will they FTBFS, just because of this change? Then this change would be OK with me.
16:45:16 <tibbs> Google turns up the old redhat.com lists first.
16:46:10 <tibbs> Doesn't this require more than just adding a line mentioning the macro to the guidelines, though?
16:46:25 <RemiFedora> before : pear package have a rm -rf %{buildroot}/usr/share/pear/.??*
16:46:39 <tibbs> I mean, if that line is now mandatory then that fact needs to be mentioned and templates updated.
16:46:46 <spot> tibbs: probably, now that i think about this. we need to describe where this new %{pear_metadir} macro should be used.
16:46:49 <RemiFedora> they need to be fixed to rm -rf %{buildroot}/var/lib/pear/.??*     (macro are only helper)
16:47:19 <tibbs> If only that macro was just defined by whatever defines the other macros.
16:48:22 <RemiFedora> tibbs, template are already update in php-pear-PEAR-Command-Packaging
16:48:47 <spot> RemiFedora: does the template use %{pear_metadir} ?
16:48:52 <RemiFedora> yes
16:48:57 <tibbs> But php-pear-PEwhatever isn't the packaging guidelines.
16:49:35 <RemiFedora> and template are only usefull for nes package
16:49:37 <RemiFedora> new
16:50:31 <spot> We could add a mini-blob that says something like "Be sure you delete any PEAR metadata files at the end of install: <pre> rm -rf %{buildroot}/%{pear_metadir} </pre>
16:50:44 <spot> s/install/%install
16:51:06 <RemiFedora> yes, could be useful
16:51:16 <spot> Lemme try that again: "Be sure you delete any PEAR metadata files at the end of %install: <pre> rm -rf %{buildroot}/%{pear_metadir}/.??* </pre>
16:51:37 <abadger1999> +1
16:51:38 <RemiFedora> spot: only 1 exception: php-pear itself
16:51:57 <spot> RemiFedora: yeah, i don't think we consider php-pear a "PEAR Module"
16:53:21 <spot> So, I propose that we add a new definition to the useful macros list: * %{pear_metadir} (This evaluates to %{pear_phpdir}, except in Fedora 19+, where it evaluates to /var/lib/pear.)
16:53:32 <spot> And we add the mini-blob I just wrote.
16:53:43 <spot> lets get a fresh set of votes on that
16:53:45 <limburgher> +1
16:53:59 <RemiFedora> spot, no %{pear_metadir} is only define in fedora 19
16:54:21 * SmootherFrOgZ here
16:54:31 <spot> RemiFedora: you need to add the define to %{pear_phpdir} to minimize spec differences.
16:54:33 <RemiFedora> of course, I can simply add it in fedora <= 18, but it will be really harder to add it in RHEL-6 ;)
16:54:37 * SmootherFrOgZ has been screwed by the timezone change :/
16:54:40 <spot> yeah, dont worry about EPEL
16:54:55 <spot> there is already stuff in the guidelines that says none of this works on EPEL.
16:55:25 <spot> i'll extend that EPEL section to cover this
16:55:25 <RemiFedora> ok, so I plan an update of php-pear in f16-f18 to add this new macro
16:55:42 <racor> RemiFedora: let me try to rephrase my concerns: can "old template"- and "new-template"-based packages coexist at runtime without causing any malfunctions or rpm-conflicts?
16:56:03 <RemiFedora> yes
16:56:22 <RemiFedora> metadata are not provided in the RPM
16:57:52 <RemiFedora> they are only present on the system, and maintain by package scriplet (/var/lib/pear.. is like /var/lib/rpm)
16:59:47 * spot is +1 on his proposal
16:59:54 <spot> which brings us to... +2! ;)
17:00:01 <rdieter> +1
17:00:34 <SmootherFrOgZ> +1
17:00:45 <tibbs> +1
17:01:26 <spot> thats +5, abadger1999, geppetto, racor, want to chime in for the record?
17:01:38 <racor> +1
17:01:39 <geppetto> +1
17:01:57 <abadger1999> +1
17:02:04 <spot> #action Add wording around %{pear_macrodir}. (+1:8, 0:0, -1:0)
17:02:20 <RemiFedora> thanks
17:02:47 * spot went ahead and committed the change since i had the EPEL page open
17:05:10 <spot> we're over an hour now
17:05:30 <spot> there is one more draft change (not related to bundling exceptions)
17:06:43 <spot> shall we continue or pick it up next week?
17:07:00 <limburgher> I'd prefer next week, but can do it now if others want to.
17:07:26 <SmootherFrOgZ> I don't mind do it now
17:07:48 <geppetto> now is fine too
17:08:17 <spot> okay, lets try now
17:08:39 <spot> #topic New mpi module install location and content - https://fedorahosted.org/fpc/ticket/229
17:08:48 <spot> Here is the diff: https://fedoraproject.org/w/index.php?title=PackagingDrafts%2FMPI&diff=308736&oldid=255947
17:09:38 <limburgher> Looks straightfwd.
17:09:53 <spot> FWIW, in my limited dealings with MPI (and the context from the bz), this all makes sense to me
17:09:57 <spot> so I'm +1 on this change
17:10:11 <abadger1999> +1 as well
17:10:26 <SmootherFrOgZ> +1 from me
17:10:26 <rdieter> +1
17:10:56 <limburgher> +1
17:10:59 <geppetto> +1 … just addition of a dir.
17:11:26 <spot> racor & tibbs, if you're still with us, and want to go on the record... :)
17:11:29 <tibbs> +1.
17:11:56 <tibbs> Had to do more reading.
17:12:12 <tibbs> And note that we no longer even have lam packaged.
17:12:15 <geppetto> yeh, would have been nice not to have the whitespace differences.
17:12:18 <racor> 0, this is all Greek to me ... I don't understand anything
17:13:11 <spot> #action Proposed changes approved (+1:7, 0:1, -1:0)
17:13:16 <tibbs> MPI is something of a pain; all of this mess is done to avoid conflicts.
17:13:25 <spot> okay, and with that, i think we're done for today, thanks everyone.
17:13:27 <tibbs> And by that, I mean Conflicts:
17:14:10 <limburgher> Thanks spot et. al.!
17:14:22 <spot> #endmeeting