16:00:28 <spot> #startmeeting Fedora Packaging Meeting
16:00:28 <zodbot> Meeting started Wed Oct 24 16:00:28 2012 UTC.  The chair is spot. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:28 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:39 <spot> #meetingname fpc
16:00:39 <zodbot> The meeting name has been set to 'fpc'
16:01:35 <tibbs> Howdy.
16:01:48 * SmootherFrOgZ waves
16:01:52 * abadger1999 here
16:02:00 <spot> #topic Roll Call
16:02:40 <spot> geppetto, rdieter, limburgher: ping?
16:04:08 * limburgher back.
16:04:18 * geppetto is here
16:04:24 <spot> okay, thats quorum
16:04:41 <spot> #topic New Java Guidelines Draft - https://fedorahosted.org/fpc/ticket/222
16:05:11 <spot> diff here: https://fedoraproject.org/w/index.php?title=User:Akurtakov/JavaPackagingDraftUpdate&diff=305374&oldid=275277
16:07:21 <geppetto> We allow .so's in jar files?
16:07:48 <tibbs> Not sure we actually talked about it before.
16:08:07 <SmootherFrOgZ> good question
16:08:11 <abadger1999> Also jnidir expands to %{_prefix}/lib/java?
16:08:22 <tibbs> My problem is, again, some of this java stuff is weird magic.
16:08:24 <abadger1999> that seems wrong for arch-specific files
16:09:11 <geppetto> abadger1999: You seen the comment right at the bottom?
16:09:21 <limburgher> .so's, or pre-built .so's?
16:10:14 <tibbs> We don't allow pre-built anything.
16:10:24 <limburgher> Right.
16:10:25 <abadger1999> ugh.
16:10:31 <limburgher> Hence my question.
16:10:38 <tibbs> I don't think anything here allows pre-built anything.
16:10:43 <abadger1999> geppetto: k.... I'd say still have to use %{_libdir}
16:10:52 <limburgher> Good, just wanted clarification.  My java-fu is weak.
16:10:54 <tibbs> The jar files themselves can't be pre-built.
16:11:10 <limburgher> No.
16:11:24 <limburgher> I've had to strip jars that couldn't be built in the past.
16:11:44 <spot> i don't think these changes imply use of pre-built so files, i think they're being built from source
16:12:03 <spot> %{_jnidir} having /usr/lib hardcoded is a problem
16:12:04 <tibbs> As far as I can tell, that's just how jni stuff works.
16:12:09 <limburgher> ok.
16:12:15 <tibbs> Java code with .so files for "glue".
16:13:16 <spot> So I suppose my only question here is: Is there any reason %{_jnidir} can't eval to "%{_libdir}/java" ?
16:13:41 <tibbs> Note current guidelines:
16:13:46 <tibbs> %{_jnidir} usually expands into /usr/lib/java.
16:14:39 <tibbs> But on 64-bit it does currently expand to %{_libdir}/java
16:14:57 <tibbs> So, "usually" is kind of incorrect, I guess.
16:15:58 <tibbs> So the big change is "%{_jnidir} usually expands into %{_prefix}/lib/java. %{_prefix}/lib64/java will cease its existence and will be decomissioned", and I guess I think that needs some justification.
16:16:46 <tibbs> There is some discussion about this in their meeting notes.
16:17:31 <tibbs> It appears that since multiarch is "close to impossible to do right", stuffing everything in /usr/lib is seen as OK.
16:17:50 <geppetto> discussion seems to be: multiarch is hard to do correctly with all the noarch stuff … so just make it go away.
16:18:12 <tibbs> Well, I am happy to see them do whatever they want with regards to multiarch.
16:18:21 <tibbs> But does that mean that /usr/lib becomes the right place?
16:18:22 <geppetto> If there is no compelling win by doing that I'd rather they didn't.
16:18:43 <spot> /usr/lib is guaranteed to exist on both targets
16:18:50 <geppetto> And I don't see a "this is a big benefit of stuffing everything in /usr/lib"
16:19:03 <geppetto> spot: So is %{_libdir}
16:19:04 <spot> </devils advocate>
16:19:12 <spot> oh, yes, i agree.
16:19:32 <spot> i'd prefer to know what specifically makes use of %{_libdir} impossible
16:19:36 <spot> before proceeding
16:19:45 <abadger1999> It seems like it isn't impossible -- just inconvenient.
16:20:08 <tibbs> I guess I've sort of lost the plot as to why we insist on lib64 for anything arch-specific if that reason isn't entirely due to multiarch.
16:20:08 <spot> i don't know why it is inconvenient, aside from the "we don't support multilib"
16:20:20 <spot> which i'm completely okay with them not caring about.
16:20:59 <geppetto> IIRC there was some discussion of eclipse stuff recently where they wanted to have %{_libdir} in noarch, and wanted it to be correct for all arches.
16:21:19 <spot> yes, but that was noarch
16:21:40 <spot> and i'm pretty sure we covered the "don't use %{_libdir} in noarch packaging, you cannot rely on it"
16:22:00 <geppetto> Yeh, but my guess is that this might be their fix for that
16:22:08 <spot> well, okay.
16:22:35 * geppetto adds quotes around "fix"
16:22:42 <spot> %python2_sitelib is precedence
16:23:10 <geppetto> But that's for the non-native stuff.
16:23:15 <spot> although, i will note that arch specific bits do end up in /usr/lib64/python...
16:23:42 <spot> so it seems like they may want to use %{_jnidir} in noarch and arch contexts
16:24:01 <geppetto> Yeh, python has python_sitelib_platform which is the jni equiv.
16:25:00 <abadger1999> errr
16:25:07 <abadger1999> python_sitearch vs python_sitelib
16:25:19 <abadger1999> at the rpm macro level
16:25:45 <geppetto> ahh … yeh, the package I'm using is old.
16:26:04 <spot> so, i guess the question is, do we care enough about this to enforce this complexity especially given that they have no plans to support multilib?
16:26:22 <spot> we could require a %{jnidir} and %{jniarchdir}
16:26:30 <abadger1999> is multilib a "Feature" -- ie a fesco question?
16:26:39 <spot> maybe.
16:26:47 <tibbs> We don't do it currently.
16:27:40 <tibbs> But there's a general question here: Do we require arch-specific stuff in %{_libdir} instead of /usr/lib even when there's no possibility of multilib?
16:27:43 <geppetto> I think they should at least provide a good reason before we let them go from "multilib. is hard, and not done" to "multilib. is incompatible with our packaging"
16:27:46 <abadger1999> If they don't support multilib... it seems like everything should get stuffed into %{_libdir}
16:27:56 <abadger1999> tibbs: right now we do.
16:28:26 <geppetto> tibbs: I would say +1, unless there's a really good reason.
16:28:26 <tibbs> Right.  But allowing this means we wouldn't.  At least not uniformly.
16:28:40 <abadger1999> <nod>
16:28:42 <tibbs> Though we might not be requiring this uniformly even now; I'm not entirely sure.
16:28:49 <spot> i wonder if it is possible to be clever with the macro such that on noarch it evals to /usr/lib/java and in all other cases uses %{_libdir}/java
16:29:02 <geppetto> Maybe not even then … although NFS mounting non-arch specific dirs. is so last millenium.
16:29:11 <limburgher> spot:  But is that wise, necessarily?
16:29:35 <spot> limburgher: well, on noarch, you don't want to be evaluating from %{_libdir}, and /usr/lib/java is a safe bet on either arch
16:29:44 <limburgher> spot: True.
16:29:50 <tibbs> Well, there's the wise thing, the possible thing and the sane thing, and they aren't always the same thing.
16:31:10 <limburgher> I'd just like to avoid some sort of macropolalypse.
16:31:14 <limburgher> c
16:31:27 <akurtakov> spot: I'm here
16:31:41 <spot> basically, the issue seems to be that some of us are uncomfortable with %{_jnidir} always evaluating to /usr/lib/java
16:31:46 <spot> instead of using %{_libdir}
16:32:32 <spot> A possible alternative is to adopt a python style split, where there is a noarch macro %{_jnidir} (/usr/lib/java) and an arch macro %{_jniarchdir} (%{_libdir}/java)
16:32:38 <akurtakov> spot: the problem is that in java many packages are noarch
16:32:50 <akurtakov> but they require arch packages
16:33:11 <akurtakov> as _libdir is not evaled properly when building noarch packages
16:33:15 <akurtakov> we don't have a choice
16:33:16 <abadger1999> spot: I don't think that helps -- jni is for  "java native interface" -- ie: things that are arched.
16:33:49 <abadger1999> akurtakov: that's untrue.  we've showed various ways of doing that.
16:34:53 <akurtakov> abadger1999: please remind me how do I do a symlink in spec file to smth that's in e.g. _libdir/java/smth.jar
16:35:34 <abadger1999> akurtakov: is the symlink only used at buildtime?
16:35:40 <akurtakov> abadger1999: yes
16:35:49 <spot> hm. i could see a reasonably simple "%{_find_arch_jar}" sort of macro that looks in the two possible targets for it
16:36:12 * abadger1999 looks for the jpackage utility that allows that
16:36:25 <akurtakov> spot: but this would not buy us anything
16:36:50 <akurtakov> spot: the jvm has no idea of multilib
16:37:05 * agrimm reads scrollback
16:37:20 <akurtakov> so even trying to has multilib packages is losing our time
16:37:31 <spot> akurtakov: if that is true, how is it finding jar files in /usr/lib64/java now?
16:37:49 <akurtakov> spot: everyone does it on his own
16:38:16 <akurtakov> in some spec file I checked for existance of 64 bit and if it's missing symlink the 32 one :)
16:38:31 <spot> akurtakov: presumably, noarch spec files.
16:38:49 <akurtakov> spot: note that the fixes depend  on the build system used
16:39:02 <akurtakov> it's one thing for ant and another for maven
16:39:31 <akurtakov> spot: http://pkgs.fedoraproject.org/cgit/piccolo2d.git/tree/piccolo2d.spec#n47
16:39:54 <akurtakov> to workaround this we install swt in libdir
16:40:05 <akurtakov> but even then I symlink it to both 32 and 64
16:40:14 <akurtakov> and one of them is obviously wrong
16:40:17 <spot> well, you could just do -f file existence checks
16:40:18 <akurtakov> it's a total mess
16:40:35 <geppetto> having two symlinks doesn't seem that bad
16:40:37 <spot> if the file exists in the 64bit location, then use that one, because the 32 bit target won't have it
16:41:05 <spot> if not, you're either on 32bit (and you know where that file is), or something else is terribly wrong and ABORT!
16:41:08 <akurtakov> well, the idea is to make packaging easier
16:41:22 <spot> akurtakov: sure, but we can macroize that 4 lines of shell
16:41:53 <spot> you could just pass in the jar file name and it would spit out the found location for the arch specific jar
16:41:58 <abadger1999> I saw a script earlier but here's a non-scripted method:  source /etc/java/java.conf
16:42:02 <tibbs> He's right; if we're enforcing the lib-lib64 split for pointless reasons then we should take a hard look at why.
16:42:24 <abadger1999> ln -s ${JNI_LIBDIR}/foo.so foo.so
16:42:36 <akurtakov> that's a case where maven uses fragments
16:42:50 <tibbs> But I don't feel like we can address grant Java an exception to that until we address the general issue.
16:42:52 <akurtakov> but sometimes artifacts are with differnt names based on arch
16:42:55 <akurtakov> and etc.
16:43:06 <spot> tibbs: not disagreeing, but if we're going to do that, i think we want FESCo to signoff on java being exempt from the standard multilib policy and permitted to put arch specific files in /usr/lib/java (technically an FHS violation on x86_64, i think)
16:43:13 <akurtakov> the real problem is that there is no unified way on the java side
16:43:30 <tibbs> spot: Right, it gets into a much larger discussion.
16:43:39 <akurtakov> spot: I thought java has this exemption as the jvm already does it ??
16:44:09 <tibbs> I don't recall any blanket exception for anything java.
16:44:21 <tibbs> I don't think FPC even had a hand in how the jvm stores its stuff.
16:44:44 <abadger1999> akurtakov: probably the jvm just does it wrong.
16:44:54 <tibbs> Sometimes things just get done without talking to anyone, and sometimes it gets done wrong.
16:44:57 <limburgher> And was grandfathered?
16:45:07 <limburgher> Sort of?
16:45:35 <abadger1999> limburgher: with heavy emphasis on sort of, maybe.
16:45:42 <spot> so, instead of arguing about it here, i propose that we ask FESCo to consider whether java is exempt from the standard multilib policy and if it has permission to put arch specific files in /usr/lib/java on all arch targets (including noarch)
16:45:45 <abadger1999> ie: FPC doesn't do enforcement
16:45:50 <limburgher> abadger1999:  That was intended. :)
16:46:04 <abadger1999> but if it is wrong, and pointed out it would need to be fixed.
16:46:06 <spot> i would encourage the Fedora Java SIG folks to make their case there
16:46:21 * spot is happy to open that ticket with FESCo
16:46:54 <akurtakov> spot: we don't want to put noarch stuff there
16:47:00 <abadger1999> The openjdk seems to have things like this: /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/headless/libmawt.so
16:47:10 <spot> akurtakov: yes, sorry, that was poorly worded on my part
16:47:23 <abadger1999> so is this two part?
16:47:28 <abadger1999> (1) exemption from multilib
16:47:42 <abadger1999> (2) arch specific files in lib instead of %{_libdir} ?
16:47:57 <spot> i think 1 implies 2, but yes.
16:48:02 <abadger1999> 1 I can agrre is fesco
16:48:07 <abadger1999> but 2 would be us.
16:48:31 <akurtakov> spot: abadger1999: fwiw - I'm asking for same threatment of jvm and other packages
16:48:48 <spot> i think if FESCo exempted java from multilib, with the understanding that it would mean that /usr/lib/java would be used for all arches, i would support that use case.
16:48:49 <abadger1999> if tghe only reason to separate lib and libdir is multilib, that seems like something we could try and pass, though.
16:48:59 <limburgher> abadger1999:  Right, because while 1 implies 2 it doesn't require it.
16:49:07 <abadger1999> akurtakov: same treatment as what?
16:49:23 <akurtakov> abadger1999: allow java packages to do like the jvm
16:49:28 <abadger1999> akurtakov: same treatment right now would be that if it's arch specific, it goes to %{_libdir}
16:49:47 <abadger1999> akurtakov: so make jvm follow what java packages do would also be acceptable?
16:49:53 <abadger1999> (ie: same treatment)
16:49:57 <akurtakov> abadger1999: NO, the jvm puts arch specific things into /usr/lib/jvm
16:50:13 <spot> abadger1999: i can confirm that the jvm is using /usr/lib on x86_64
16:50:25 <abadger1999> akurtakov: exactly.  So same treatment would be -- make the jvm put the arch'd bits into %{_libdir}
16:50:34 <akurtakov> in /usr/lib
16:50:44 <spot> abadger1999: he means "same treatment as the jvm is being permitted to do now"
16:50:50 <akurtakov> unless the jvm multilib handing is improved internally
16:51:05 <akurtakov> which would not happen magically
16:51:47 <spot> is anyone opposed to asking fesco if java (including the jvm) is exempt from multilib?
16:51:53 <limburgher> Not at all.
16:51:53 <abadger1999> ah I think the script I was looking for is /usr/bin/build-classpath
16:52:06 <abadger1999> /usr/bin/build-classpath java_cup => /usr/share/java/java_cup.jar
16:52:16 <spot> i think that detail will shed light on whether we grant permission for universal arch use of /usr/lib/java for x86 && x86_64
16:52:18 * SmootherFrOgZ isn't
16:53:07 <akurtakov> spot: abadger1999: note that System.loadLibrary will need improvements too if one wants java to be truly multilib
16:53:31 <spot> akurtakov: i think you will want to make your case as to why java is exempt from multilib in the fesco ticket. :)
16:53:40 <abadger1999> <nod>
16:53:42 * spot will open the ticket and send you the #. :)
16:53:59 <akurtakov> tbh, I'll let sochotni do it as he has been dealing with this change :)
16:54:04 <abadger1999> multilib was a Fedora "Feature" from back before the unified repos.
16:54:20 <abadger1999> the aspect of multilib we're considering might even have been a RHL feature.
16:54:29 <akurtakov> I gave up on writing guidelines about that long ago :)
16:55:52 <abadger1999> Shall we also have a followup for FPC -- things that do not attempt to use multilib do not need to use libdir?
16:56:38 <spot> abadger1999: lets worry about that if FESCo says something is exempt
16:56:46 <spot> akurtakov: https://fedorahosted.org/fesco/ticket/961
16:56:52 <tibbs> I would tentatively be behind such a thing, but I'd really have to think about it more.
16:57:01 <abadger1999> okay... it has applications to certain other things that we've had difficulty with too.
16:57:13 <abadger1999> So it would be good to hammer that out regardless.
16:57:19 <abadger1999> For instance, arch-specific data files
16:57:29 <spot> btw, a strict reading of the FHS does not prevent this case, it merely states that /usr/lib<NN> can be used, but it does not require it
16:57:36 <abadger1999> <nod>
16:57:46 <tibbs> Yes, that was my understanding.
16:57:50 <spot> although, it is worth noting that i doubt this situation was conceived of when the FHS was written
16:58:26 <limburgher> Like many things, Horatio.
16:58:45 <spot> #action FPC will wait on Java draft until an answer for FESCo ticket 961 is received
16:58:52 <spot> and we're at the hour.
16:59:58 <spot> there are several bundling requests pending
17:00:11 <spot> and the hylafax conflicts issue
17:00:14 <tibbs> I'm still around.
17:00:18 <limburgher> I can't stay.
17:00:23 <tibbs> I will recuse myself from the hylafax issue.
17:00:51 <geppetto> Can we all do a quick bunch of -1's for the version naming ticket?
17:01:02 <tibbs> Yes, -1 from me.
17:01:18 <geppetto> 227
17:01:24 <geppetto> and, yeh, -1 from me.
17:01:45 <SmootherFrOgZ> -1
17:01:49 <spot> #topic Multiple packages with the same base name versioning - https://fedorahosted.org/fpc/ticket/227
17:02:19 <geppetto> -1
17:02:27 <spot> the only point i would make is that while i am opposed to making this sort of logic a must
17:03:14 <spot> in most cases where a newer version obsoletes an older one, i would hope that it eventually emerged in an unversioned name
17:04:19 <spot> but as an absolute, i'm -1 here
17:04:48 <tibbs> I would not object to more fleshing out of that section of the naming guidelines.
17:04:59 <tibbs> http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Multiple_packages_with_the_same_base_name
17:05:13 <spot> tibbs: me neither, but i think that probably looks a lot more complex than what vondruch is proposing here
17:05:26 * limburgher pops in for a -1
17:05:36 <spot> e.g. gambas upstream supporting gambas 2 and gambas 3 simultaneously with incompatible APIs
17:05:52 <spot> which one is "gambas" ? :)
17:05:56 <geppetto> spot: Yeh, I understand … and I kind of assume that's what the OP was thinking about. But trying to put that in policy feels a lot like saying "use your common sense".
17:06:11 <spot> (the answer, neither, gambas 1 was "gambas")
17:06:19 <geppetto> ha
17:06:19 <tibbs> There have been a number of proposals that reduce to "use common sense".
17:06:57 <abadger1999> tibbs: +1
17:07:00 <tibbs> It seems that some folks think that any time there's disagreement in a review ticket, the guidelines need to be updated to answer whatever specific question was raised.
17:07:03 <spot> i could even see policy to encourage that the most recent version of a multi-version packaged package provides the common name
17:07:36 <spot> (assuming, obviously that another package doesn't have the common name already, see above with gambas)
17:07:43 <abadger1999> It would also be good to canonicalize the difference between compat-foo and foo$VER but I guess that's another draft.
17:07:58 <spot> someone with a bit more sanity left than me should tackle this one.
17:08:32 <spot> We're at -4 on this issue, which means it cannot receive +5 based on the present attendees
17:09:06 <spot> one more -1 and we can mark it as rejected... or we can table it without any additional votes.
17:09:19 <abadger1999> Anyhow, -1 to proposal as written
17:09:29 <geppetto> abadger1999: Yeh, that one is more draft worthy … as it's kind of random.
17:09:41 <spot> #action -5 votes, this proposal (as written) is rejected.
17:10:07 <geppetto> abadger1999: And it would actually be nice is that was a single std. for naming (eg. drop all compat- prefixes).
17:10:20 <geppetto> s/is that/if there/
17:10:56 <abadger1999> geppetto: well... in the past, compat-* signified "runtime libraries, no header files", whereas foo${VER} meant parallel installable devel and runtime.
17:11:20 <abadger1999> but that's gotten increasingly muddy over the years since there's nothing written
17:11:39 <geppetto> abadger1999: yeh.
17:11:52 <geppetto> abadger1999: non-C languages don't help :)
17:11:58 <abadger1999> geppetto: yeah :-)
17:12:27 <spot> okay, i think with that we're done for this week
17:12:29 <spot> thanks everyone
17:12:44 <spot> #endmeeting