15:05:40 <abadger1999> #startmeeting fpc
15:05:40 <zodbot> Meeting started Wed Jun 15 15:05:40 2011 UTC.  The chair is abadger1999. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:05:40 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:05:46 <abadger1999> #meetingname fpc
15:05:46 <zodbot> The meeting name has been set to 'fpc'
15:06:08 <abadger1999> #chair limburgher tibbs|h geppetto racor spot rdieter_work SmootherFrOgZ
15:06:08 <zodbot> Current chairs: SmootherFrOgZ abadger1999 geppetto limburgher racor rdieter_work spot tibbs|h
15:06:09 <tibbs|h> I wonder if spot has a scheduling conflict.  He hasn't been around for a couple of weeks now.
15:06:25 <rdieter_work> hola
15:06:39 <limburgher> I seem to recall seeing Tweets re: travel.
15:07:22 <geppetto> last week something came up at the last minute
15:07:46 <geppetto> this week, I'm not sure … he had been traveling, but was back yesterday
15:07:48 <limburgher> Tweeted re: Hockey 6/13.
15:10:35 <abadger1999> Okay, speculation doesn't seem to be summoning him :-)
15:11:11 <limburgher> I have a circle of alternating black and white candles and a guinea pig, should it come to that.
15:11:17 <abadger1999> I see two new tickets and several old ones that were waiting on information gathering.
15:11:35 * abadger1999 starts with the new ones
15:11:55 <abadger1999> #topic Change mono library directory from %{_libdir} to /usr/lib
15:11:59 <abadger1999> https://fedorahosted.org/fpc/ticket/91
15:12:18 <abadger1999> https://fedoraproject.org/wiki/User:Chkr/MonoMultiarchChanges
15:13:10 <abadger1999> I have to admint, I've become more attuned to the idea that python/perl/mono/other language byte code could be considered to belong to /usr/lib in the FHS over time.
15:14:13 <geppetto> I don't see how/why that would be true … but I don't mind too much breaking the rules and putting them there (instead of /usr/share) if it helps our packagers a lot
15:14:18 <tibbs|h> My opinion hasn't changed, but I'm getting close to not caring as it seems that nobody else really seems to care about the share/lib distinction any longer.
15:15:01 <abadger1999> What's changed upstream since we first looked into this is that upstream used to insist that the assemblies could be arch specific but now have agreed that if an assembly is arch specific it should be treated as a bug.
15:15:31 <abadger1999> So that makes %{_libdir} less appropriate.
15:15:32 * rdieter_work is with abadger1999 , and tibbs|h (the not caring part)
15:15:45 <tibbs|h> Which does change the answer to our original question: is share more appropriate or lib/lib64.
15:15:55 <abadger1999> Yeah.
15:16:30 <racor> I just checked a suse package and they use /usr/lib64
15:17:10 <geppetto> racor: for the arch non-specific .dll files?
15:17:19 <tibbs|h> They might have taken their lead from us, though.
15:17:22 <limburgher> If it's really truly honestly noarch, I'd prefer /usr/share, but not militantly so.
15:17:43 <racor> the *.dlls are in /usr/lib/mono/....
15:17:51 <tibbs|h> The real question is why there's disagreement about this.
15:18:11 <tibbs|h> Is it different interpretations of the FHS, or is it that upstream made the wrong choice in the beginning and now changing it is difficult?
15:19:20 <racor> IMO: Lack of multilib experience ...
15:19:50 <tibbs|h> All I really saw was some attempt to sort of make some odd arguments that it really isn't that much of an FHS violation to put them in /usr/lib, which sounds to me like trying to find some way to justify a mistake made in the past.
15:21:03 <tibbs|h> In the end I'm not much of an FHS expert.
15:21:25 <geppetto> Yeh, and I don't think it's that difficult for upstream to fix it to /usr/share … but it's a lot more work for our packagers to do so, AIUI
15:21:52 <tibbs|h> Oops.
15:22:20 <abadger1999> Sorry, dropped off three minutes ago.
15:22:21 <tibbs|h> Circumstances seem to be conspiring against us.
15:22:43 <tibbs|h> http://fpaste.org/dxou/
15:22:49 <abadger1999> Thanks
15:25:02 <rdieter_work> so, as far as I'm concerned, I'm ok and +1 with the changes proposed in ticket 91
15:25:10 <tibbs|h> Anyway, I'm willing to be pragmatic/magnanimous if it's established that fixing things to use /usr/share is still hard and a source of bugs, and nobody who knows the FHS well has any massive objections.
15:25:21 <tibbs|h> I think we can assume that there's no chance of convincing upstream.
15:25:35 <rdieter_work> yeah, seems that way at this point
15:25:57 <limburgher> tibbs|h: +1
15:26:21 <tibbs|h> Honestly I think racor is the resident FHS expert and I'd like to hear if he has any objections.
15:26:27 <geppetto> Well I think traditionally the idea was that /usr/share could be NFS mounted over multiple machines of different arch. … but pretty much nobody does stuff like that now
15:26:30 <abadger1999> +1
15:26:45 <racor> tibbs|h: I am not familiar with mono
15:27:00 <tibbs|h> Fortunately neither am I.
15:27:15 <Rathann> hi everyone
15:27:20 <Rathann> sorry
15:27:24 <Rathann> for being late
15:27:31 <tibbs|h> Do you have scrollback?
15:27:38 <racor> 0, proposal table this proposal. IMO, this proposal is a regression and is trying to adopt and propagate the mistakes e.g. perl suffers from.
15:28:04 <Rathann> tibbs|h: no, just joined
15:28:05 <tibbs|h> Sorry, which mistakes does Perl suffer from?  I thought it got this right.
15:28:18 <limburgher> Are we thinking about trying to fix everything else?
15:28:30 <tibbs|h> Rathann: http://fpaste.org/SJ2D/
15:28:33 <geppetto> tibbs|h: no, both perl and python do the same thing (put pure noarch package files in /usr/lib/*)
15:29:01 <racor> tibbs|h: not respecting multilibs and squeezing everything into /usr/lib.
15:29:37 <Rathann> tibbs|h: thanks
15:29:38 <tibbs|h> For some reason I thought perl was using /usr/share for things now.
15:29:46 <geppetto> limburgher: AIUI there had been proposals to fix both perl and python … but they never got done
15:30:00 <racor> it is the origin of problems perl has with "arch'ed dir" handling.
15:30:16 <geppetto> Hmm … interesting … perl-DateTime is in /usr/share
15:30:17 <tibbs|h> Arch-independent perl modules seem to be going under /usr/share/perl5 for me.
15:30:24 * spot apologizes for being late
15:30:24 <tibbs|h> Arch-dependent ones go into _libdir.
15:30:26 <spot> i had massive hardware failure this morning
15:30:36 <limburgher> gepetto: I think it should get done at some point, but it's going to hurt and I have no idea how to do it gracefully and without bringing on pitchforks.
15:30:46 <abadger1999> limburgher: Yeah, python has been listed as don't want to fix, must I? by the maintainer and we haven't really found a good reason to say "yes, you must".
15:31:07 <geppetto> Well … the fact perl seems to be fixed is a pretty good reason
15:31:29 <spot> to be fair, i think this is a slightly different case, from what i understand of the mono space
15:31:31 <geppetto> And python could move over gradually (Eg. having core support both for a bit)
15:31:32 <limburgher> abadger1999:  Yeah, it's not like we're going to drop it from the distro.
15:31:53 <spot> the idea is that these packages should be treated as pseudo-noarch
15:31:56 <limburgher> gepetto:  And no kittens would be at major risk?
15:32:17 <racor> geppetto: Yes, there was a time Fedora's perl applied a /usr/share for no-arch'ed modules. Things had changed several times, since then, but I got sufficiently disattracted from perl to know the current state.
15:32:19 <spot> the mono DLL object is "supposed" to work anywhere
15:32:34 <spot> but it is compiled, and it is clearly not wholly arch independent
15:32:51 <geppetto> limburgher: I don't think so … but I haven't tried it :)
15:33:18 <limburgher> gepetto: <nods>
15:33:19 <geppetto> The same thing could be said about .pyc files … so without some proof I'm willing to believe that .dll files are just as noarch
15:33:29 <spot> so, i think the question is: Do we permit these odd DLL objects to always end up in /usr/lib or do we force them to be multilib without any support from upstream?
15:33:41 <tibbs|h> The thing is, either it's arch-dependent or independent.  dependent -> _libdir, independent -> /usr/share.  What am I missing here?
15:33:58 <spot> it isn't really arch independent, IMHO, in my reading of the FHS
15:34:05 <spot> these are compiled objects
15:34:22 <geppetto> spot: From what I understand now the choice is really … should we force them into /usr/share, without upstream support … or should we let them break FHS and go into /usr/lib (but make packaging a lot easier)
15:34:37 <spot> /usr/lib64/mono/gac/Mono.Reflection/1.0.0.0__046ed8ba4eae38ad/Mono.Reflection.dll: PE32 executable (DLL) (console) Intel 80386 Mono/.Net assembly, for MS Windows
15:34:49 <spot> note the arch specific nature of that
15:34:53 <abadger1999> FHS definition /usr/lib (specifically "lib", not %_libdir)  and %_datadir are sufficiently vague that archindependent libraries could go to either.
15:35:14 <abadger1999> as they're executed code, not data
15:35:20 <abadger1999> but they're arch independent code.
15:35:28 <spot> my feedback is that since mono is retard...special anyways, /usr/lib is the simplest solution for the packager
15:35:43 <spot> i don't feel that /usr/share is correct
15:35:47 <rdieter_work> spot: nice summary, +1
15:35:47 <mjg59> spot: Relatively sure that the 80386 aspect of that is an artifact
15:35:54 <geppetto> blah … as I said, I'm not buying that distinction, really … they are bytecode that happens to be (or look like) i386 asm
15:36:07 <spot> mjg59: perhaps, but the thing is compiled with optflags for at least intel
15:36:11 <tibbs|h> The problem is that if we could justify a lot of things by just going for the simplest solution for the packager.
15:36:22 <tibbs|h> Ignore that first "if".
15:36:31 <spot> tibbs|h: yes, true, but in this case, our choices are:
15:36:51 <spot> A) Continue to apply arbitrary multilib split that NO other distro does and upstream will not accept patching for
15:37:05 <spot> B) Permit /usr/lib, which upstream supports and every other distro does
15:37:18 <spot> C) /usr/share, which upstream does not support and no other distro does
15:37:22 <tibbs|h> I thought suse counted as one other distro as established earlier.
15:37:36 <tibbs|h> Maybe I misunderstood what they're putting in _libdir.
15:37:38 <spot> tibbs|h: i could be wrong, but i do not believe suse multilibs mono
15:37:52 <spot> i do not think there are any mono objects in /usr/lib64 on x86_64
15:37:55 <spot> (on suse)
15:38:13 <racor> openSUSE: rpm -qlvp mono-core-2.8.2-0.2.3.x86_64.rpm | grep lib64
15:38:15 <tibbs|h> I'm just going by:
15:38:19 <tibbs|h> [10:16] <racor> I just checked a suse package and they use /usr/lib64
15:38:26 <racor> -rwxr-xr-x    1 root    root                   238184 Feb 23 10:46 /usr/lib64/libMonoPosixHelper.so
15:38:36 <spot> racor: yes, but those are C objects, not DLLs
15:38:48 <spot> this proposal is not to move the C objects out, just the mono assembly
15:38:55 <racor> Correct, the dlls are in /usr/lib/mono/*
15:38:55 <abadger1999> yeah, that's the "glue libraries" that upstream mentioned in their emails.
15:40:13 <spot> I see no technical benefit to putting them in /usr/share, especially given that it will add significant extra work for mono packagers and that it is not supported by upstream or other distros
15:40:29 <spot> we can argue for days about whether the DLL assemblies are arch specific or not
15:41:05 <tibbs|h> Well, we could just trust upstream for that.
15:41:08 <limburgher> It's true, there's precedent for that.
15:41:08 <spot> however, i think at the end of the day, this proposal simplifies packaging of mono and brings us into parity with the other distributions
15:41:40 <tibbs|h> So we accept that we're basically approving an FHS exception here?
15:41:42 <spot> upstream says "these go into /usr/lib/mono", they don't pollute the ld.so cache at all, so i'm inclined to approve it
15:41:46 <spot> tibbs|h: *nod*
15:41:50 <racor> spot: If they go to /usr/lib they must be arch independent
15:42:08 <tibbs|h> Upstream says they are.  Have we reason not to trust them?
15:42:09 <spot> racor: upstream says they are
15:42:19 <tibbs|h> (Besides that they've just change their answer to that question, of course.)
15:42:21 <racor> tibbs|h: If they are arch-dependent, we are sanctioning an arch-violation
15:42:25 <spot> and i really dont want to argue with miguel.
15:43:09 <spot> Based on the available information from upstream and other distributions
15:43:12 <spot> i'm +1 here
15:44:11 <geppetto> I'm +1, knowing that /usr/share is "better" … but a lot more work, and we'd be the only one
15:44:12 <rdieter_work> +1 (again)
15:44:22 <abadger1999> +1
15:44:28 <Rathann> I concur, +1 from me as well
15:44:34 <limburgher> +1
15:45:18 <spot> tibbs|h, racor, SmootherFrOgZ, if you'd like to vote on the record, now would be the time
15:45:30 <tibbs|h> I'm kind of sad about basically knowing that we know what the "right" thing is but we don't feel it worth the effort to do it.
15:45:46 <tibbs|h> I'm just trying to keep my dislike of mono from getting in the way of pragmatism.
15:45:55 * abadger1999 not sure that /usr/lib is an FHS violation here.
15:46:00 <tibbs|h> So, +1, I guess.
15:46:16 <tibbs|h> I did not buy the arguments about it not being an FHS violation.
15:46:22 <abadger1999> <nod>
15:46:44 <spot> #action Mono change to /usr/lib approved: (+1:7, 0:0, -1:0)
15:47:02 <abadger1999> I guess that's a personal note -- I'm okay voting +1 as I'm not convinced that it is an FHS violation.
15:47:25 <tibbs|h> If it's not an FHS violation, there's actually no issue here except for modifying the guidelines.
15:47:28 <abadger1999> #chair spot
15:47:28 <zodbot> Current chairs: SmootherFrOgZ abadger1999 geppetto limburgher racor rdieter_work spot tibbs|h
15:47:41 <spot> #action Mono change to /usr/lib approved: (+1:7, 0:0, -1:0)
15:47:47 <spot> (just to make sure it hits the logs)
15:47:57 <spot> did we talk about ticket 92 at all?
15:48:01 <limburgher> Not yet.
15:48:04 <abadger1999> spot: Noope, this is the first ticket
15:48:28 <tibbs|h> Note I have a hard stop coming shortly after the hour.
15:48:33 <spot> #topic Ticket 92 - Look into relaxing Conflicts Guidelines - https://fedorahosted.org/fpc/ticket/92
15:48:37 <racor> Sorry, distrupted  by the phone: My vote: 0 - I don't think it's an FHS violation, but I think it's wrong.
15:49:09 <tibbs|h> I don't think we've been asked to evaluate a conflict in ages.
15:49:26 <tibbs|h> Why would we worry about relaxing the guidelines when we could just evaluate this case?
15:49:45 <spot> so, to be fair, my understanding was that Conflicts were not forbidden, but we wanted to make sure that the case really REALLY merited their use
15:49:51 <abadger1999> So couple options -- we could relax the Conflicts Guideline, we could add the specific type of case I found to the whitelist, or we could wait to find out why alternatives doesn't work there.
15:50:10 <spot> abadger1999: my gut instinct is to add the specific case to the whitelist
15:50:20 <abadger1999> s/couple/cup a' three/
15:50:28 <spot> i don't want to go back to FC2 era spec files, where we had Conflicts all over
15:50:42 <Rathann> what's the real problem here? that zabbix supports many db interfaces, but can use just one at any given time?
15:50:45 <abadger1999> We do still have tons of conflicts.
15:50:52 <spot> abadger1999: not on the same scale
15:50:56 <rdieter_work> Rathann: I believe that's the case, yes
15:51:13 <rdieter_work> Rathann: with no runtime selection mechanism either
15:51:21 <spot> that seems like a reasonable enough whitelist item
15:51:22 <tibbs|h> Certainly we don't want to relax the rule about implicit conflicts.
15:51:26 <abadger1999> heh, yeah, having the Conflict guideline this draconian does let us smack people over the head.
15:51:35 <abadger1999> tibbs|h: +1, that isn't going away.
15:51:46 <spot> i think we can document this specific, narrow case
15:51:55 <tibbs|h> We really need a tool for taking a package and seeing if it has any conflicts with the entire package set.
15:52:05 <rdieter_work> this particular case could well use alternatives, but that's always a painful solution
15:52:07 <geppetto> To be fair … I can see some problems here … "yum install" will get upset in certain cases, and just fail … "yum install blah\*" will always fail … and there's no good way to have a default
15:52:12 <tibbs|h> That could be run at review time and perhaps by autoqa.
15:52:20 <geppetto> All of which would be solved if we "forced" them to use alternatives
15:52:25 <abadger1999> spot: So the reason I bring up relaxation is that both geppetto and I have pointed out that alternatives probably would work in this case.
15:52:29 <tibbs|h> geppetto: Yes, that's why the guideline is so strong.
15:52:42 <spot> abadger1999: so, why is alternatives not a good solution here?
15:52:47 <tibbs|h> We knew at the time that the tools handled conflicts pretty badly.
15:52:51 <spot> abadger1999: is it because it is too intrusive?
15:53:00 <abadger1999> so the question is -- are we strict about this and therefore we force alternatives on package maintainers/other workarounds.
15:53:03 <geppetto> I'd guess they just didn't think of it
15:53:27 <tibbs|h> We should certainly force workarounds where it's possible.
15:53:43 <abadger1999> Or do the benefits of being that strict not justify being that strict?
15:53:48 <tibbs|h> And we should ask for some reason those workarounds don't work in the specific case we're asked to evaluate.
15:53:48 <rdieter_work> abadger1999: I'd err on the side of saying yes (being strict), unless there's some strong exceptional reasons otherwise
15:54:01 <tibbs|h> Maybe we need a questionnaire like we do for bundling exceptions.
15:54:02 <spot> yeah, i think this is a case where i do not want to encourage laziness
15:54:15 <abadger1999> Our written benefits section is pretty weak, I think.
15:54:23 <spot> if someone says "here are the technical reasons why i have no other sane alternative to Conflicts", then okay
15:54:26 <spot> but i don't see that here
15:54:39 * geppetto nods
15:54:39 <tibbs|h> As far as I'm concerned, "the tools don't handle it well at the moment" is quite sufficient reasoning.
15:54:43 <abadger1999> The side effect of letting us club people who use Conflicts incorrectly is better justification IMHO, but that's not written in the guidelines.
15:54:53 <spot> it would probably be helpful to flesh out the Conflicts section to help people find those alternative options
15:55:13 <tibbs|h> Quite sufficient reasoning to seriously restrict conflicts, that is (if it wasn't clear).
15:56:00 <spot> So, I'm -1 on relaxing Conflicts, +1 to a draft of improving the Conflicts section(s) to better explain why things are strict and point to other options
15:56:40 <tibbs|h> Of course, I guess it's fair to add that alternatives make yum not fail weirdly but alternatives sure aren't pretty for the person who has to figure them out.
15:56:47 <racor> spot: +1 to your last sentence.
15:57:16 <tibbs|h> spot: +1 to all of what you just wrote.
15:57:49 <tibbs|h> Why on earth does the alternatives tool not have a "--list" option?  How do I even know what alternatives I'm able to select?
15:58:49 <limburgher> +1
15:59:48 <spot> so, it doesn't seem like there is quorum for relaxing Conflicts
15:59:55 <Rathann> +1
16:00:05 <abadger1999> +1 here as well.
16:00:08 <Rathann> tibbs|h: I thought it does have such an option
16:00:15 <geppetto> spot: even more, I'm pretty sure everyone agrees with you :)
16:00:19 <spot> abadger1999: would you like to take a shot at improving what is there? :)
16:00:32 <Rathann> tibbs|h: --display
16:00:46 <tibbs|h> Rathann: Nope.
16:00:50 <tibbs|h> At
16:00:54 <tibbs|h> least not on F14.
16:01:02 <geppetto> "echo | alternatives --config blah" is kind of like --list
16:01:19 <geppetto> Opening an RFE for --list wouldn't be a bad thing though :)
16:01:47 <abadger1999> Not really -- I haven't been able to think of a nice way to word it.
16:01:50 <geppetto> also some option to list all things which are alternatives might be nice
16:02:06 <tibbs|h> That's what I'm talking about.
16:02:09 <spot> okay then, would anyone here like to work on an improved version of the Conflicts section?
16:02:19 * spot just doesn't have the spare cycles right now
16:02:21 <abadger1999> spot: I could definitely add links to alternatives and environment-modules guidelines.
16:02:47 <abadger1999> Just the improving the benefitsto Fedora section that I couldn't figure out.
16:02:49 <spot> abadger1999: okay, at a minimum, that seems like a no-brainer
16:02:58 <spot> abadger1999: i say just go ahead and make that change
16:03:04 <tibbs|h> I have to apologize, but as I've temporarily acquired a daughter I've even less time than normal for Fedora stuff.  Which pretty much means no time at all.
16:03:18 <spot> tibbs|h: thanks for your time, i think we're pretty much done for today anyways
16:03:58 <spot> #topic Open Floor
16:04:04 <limburgher> k.
16:05:20 <spot> if there is nothing by, oh, 1608, i'll close the meeting out
16:05:26 <abadger1999> #action abadger1999 to link Conflicts guidelines to altrnatives and env-mod; need someone to expand conflicts benefits section.
16:06:36 <abadger1999> Oh just an FYI:
16:06:53 <abadger1999> epel decided that python26 subpackage vs separate package would be maintainer choice
16:07:04 <spot> interesting, okay.
16:07:13 <abadger1999> (since stable python mods are easier to do as subpackages)
16:07:34 <abadger1999> I'm improving their documentation to state why/when subpackages are a bad idea.
16:07:47 <abadger1999> So that it's clearer when to use one or the other.
16:07:48 <spot> ok
16:08:15 <geppetto> sounds fine
16:09:11 <spot> alrighty then, thanks everyone, and GO BRUINS.
16:09:15 <spot> #endmeeting