From Fedora Project Wiki

Fedora Packaging Committee Meeting of {2008-04-22}

Present

  • DenisLeroy (delero)
  • DominikMierzejewski (Rathann|work)
  • HansdeGoede (hansg)
  • JasonTibbitts (tibbs)
  • RexDieter (rdieter)
  • TomCallaway (spot)
  • ToshioKuratomi (abadger1999)
  • XavierLamien (SmootherFrOgZ)

Writeups

The following drafts have been accepted by FESCO and are to be written into the guidelines:

  • No packages may own files or dirs in /srv:

http://fedoraproject.org/wiki/PackagingDrafts/NoBitsInSrv

  • Build GCJ AOT bits conditionally

http://fedoraproject.org/wiki/PackagingDrafts/ConditionalGCJ

Votes

The following proposals were considered:

held to grant it an exception which passed with the following voting for: Rathann spot tibbs hansg rdieter

Other Discussions

The following additional items were discussed; see the logs for full details.

a usable set of guidelines.

  • Discussions about possibly moving the meeting time to account for DST will

happen on-list.

IRC Logs

[12:02]  * spot pings racor, hansg, abadger1999, delero, SmootherFrOgZ, tibbs
[12:02]  <tibbs> "SmootherFrOgZ"?
[12:02]  <delero> hi
[12:02]  --> Rathann has joined this channel (n=rathann@onizuka.greysector.net).
[12:03]  * hansg is present
[12:03]  <spot> and there's Rathann. :)
[12:03]  <Rathann> present
[12:03]  <Rathann> (semi-)
[12:03]  * Rathann is fiddling with audio cables
[12:03]  <SmootherFrOgZ> tibbs, yep ?
[12:04]  <spot> tibbs: so, spot is ok, but you draw the line at "SmootherFr0gZ" ? :)
[12:04]  <tibbs> I simply have no idea who this person is.
[12:04]  * abadger1999 is late but here now.
[12:05]  <spot> tibbs: he's one of our two new members, specifically, Xavier Lamien
[12:05]  <tibbs> Whatever happened to Panu?
[12:05]  <spot> delero is our other new member, aka, Denis Leroy
[12:05]  <spot> tibbs: thats how the vote came out.
[12:05]  * delero raises his hand
[12:05]  <tibbs> Hmm, disappointing.
[12:07]  <spot> anyways. :)
[12:07]  <spot> i don't see racor or abadger1999 awake, but everyone else is alive
[12:08]  <abadger1999> I'm here, I'm here!
[12:08]  <spot> ok, so thats 8 of 9
[12:08]  * abadger1999 jumps up and down
[12:08]  <spot> lets get to the first item of business
[12:08]  <spot> abadger1999: is Javascript ready?
[12:08]  * hansg wonders why someone is jumping up and down, adhd?
[12:09]  <abadger1999> spot: It can be discussed.
[12:09]  <spot> ok. first item is: http://fedoraproject.org/wiki/PackagingDrafts/Javascript
[12:09]  <abadger1999> I'm satisfied with it but I'm also happy to kick the completed draft out to the list one more time.
[12:10]  <tibbs> The issues surrounding this are weird enough that I'd really like to see some input from upstream developers of some of the packages which would fall under this guideline.
[12:10]  <abadger1999> Okay.  What questions would you like to see specifically asked and answered?
[12:10]  <abadger1999> I know I'll get pushback from upstream.
[12:11]  <tibbs> Specifically, the mootools stuff is just nuts, and the compression issue.
[12:11]  <abadger1999> It'll be a matter of whether concerns like security trump what upstreams perceive as easiest.
[12:11]  <abadger1999> Okay.  So talking to mootools and a few of the mootools consumers.
[12:12]  <tibbs> Well, here's the problem.  I have to package mootools in some form in order to update zoneminder.
[12:12]  <tibbs> And this guideline doesn't actually help me do that.
[12:12]  <abadger1999> <nod>
[12:12]  <abadger1999> Very true, that.
[12:12]  <tibbs> I mean, I could package the exact mootools bits that zoneminder needs, but then that should go in zoneminder and thus would be forbidden by this guideline.
[12:13]  <tibbs> So for the only real-world example that I have interest in, it's counterproductive.
[12:13]  <spot> perhaps working through mootools might provide a good basis for fleshing out this guideline?
[12:13]  <abadger1999> I don't believe there's any work to do something like this anywhere else.
[12:13]  <tibbs> We could package all ~8192 versions of mootools separately.
[12:13]  <delero> is the mootools issue really javascript-specific, or is mootools a special case ?
[12:14]  <tibbs> Oops, there are three or four compressors you can apply, so that's too small.
[12:14]  <tibbs> Well, mootools is a javascript library.
[12:14]  <abadger1999> Can we package the complete mootools package as separate files by working with their source?
[12:14]  <rdieter> mootools sound like a pathelogical special-case to me.
[12:14]  <tibbs> abadger1999: I don't believe so.
[12:14]  <abadger1999> Or..hmm... No I see the problem with that.  URLs in the zoneminder package...
[12:14]  <tibbs> rdieter: Yes, but "A package MUST not include javascript libraries that have a separate upstream."
[12:14]  <Kevin_Kofler> IMHO you should make clear that this is only for JavaScript stuff which is part of a web app. There's going to be plenty of JavaScript stuff in future versions of KDE 4 which has nothing to do with Apache and thus "MUST: A javascript library package must provide an apache config file that lets the library be served by apache. This file is placed in %{_sysconfdir}/js/ with a filename extension of *.conf" makes no sen
[12:14]  <Kevin_Kofler> se without defining "javascript library".
[12:15]  <rdieter> tibbs: guidelines remember, can have exceptions
[12:15]  <rdieter> Kevin_Kofler: Javascript library with separate upstream.
[12:15]  <abadger1999> Kevin_Kofler: That's a good point.  Will there be javascript libraries in KDE4?
[12:16]  <tibbs> There are some in KDE3 already, aren't there?
[12:16]  <abadger1999> ie: libraris of javascript code... but intended for building non-web applications?
[12:16]  <delero> with seperate usptream + "and managable release mechanism" ?
[12:16]  <spot> delero: thats really vague.
[12:16]  <abadger1999> delero: We've never let "managable release mechanism" stop us before.
[12:16]  <delero> spot: i agree
[12:16]  <Kevin_Kofler> There are bindings for C++ stuff to use with JavaScript (and there will be one for libplasma), not sure about actual JS libraries.
[12:17]  <rdieter> upstreams without a managable release mechanism deserve cluestick treatment, regardless.
[12:17]  <spot> i think perhaps mootools might need to be a special case, given the large number of variants
[12:17]  <tibbs> For web-intended javascript outside of mootools, I think this guideline serves us well although the compression but gets tricky with the "must rebuild from source" bit.
[12:17]  <spot> tibbs: perhaps we could use all of their compression methods?
[12:17]  <tibbs> "compression bit gets tricky".
[12:17]  <abadger1999> Kevin_Kofler: Okay.  I'd say that qualifies... So the "separate (sub)package" part would still apply.  But the config file should be make clear that it doesn't apply
[12:18]  <tibbs> Well, do we have the actual compressors as installable packages in Fedora?
[12:18]  <spot> tibbs: i dunno. worth checking at least.
[12:18]  <tibbs> I.e. is it intended that we not take the pre-compressed source from upstream?
[12:18]  <abadger1999> tibbsWe are missing at leat jsmin.
[12:18]  <abadger1999> So I think we aren't able to compress at this time.
[12:19]  <abadger1999> tibbs: Yes.  That is intended.
[12:20]  <abadger1999> The minified stuff is technically javascript still, but it's extremely hard to read.  The actual compressed stuff has to be uncompressed in order to read.
[12:20]  <tibbs> There's GPL interaction with that stuff, too, with the "usual form for making modifications" clause.
[12:21]  <tibbs> I don't even want to think about how putting compressed GPL javascript code on your web site involves "distribution".
[12:22]  <abadger1999> <shivers>
[12:22]  <tibbs> I think it's pretty obvious that we should always have the uncompressed version available.
[12:23]  <abadger1999> As in, in the binary rpm?  Or just in the source rpm?
[12:23]  <tibbs> In the web-accessible location.
[12:23]  <spot> i suspect (from what i'm hearing here, not from personal opinion) that many javascript libraries will be incredibly painful to package
[12:23]  <tibbs> Well, actually most of them are trivial.
[12:23]  <tibbs> It's just that the issues are complicated.
[12:23]  <tibbs> All you have to do is stick them in a location and drop in an apache redirect.
[12:24]  <tibbs> Also, I recall recent grumbling about how that stuff doesn't work at all with another web server.
[12:25]  <abadger1999> spot: Yes.  Although ivazquez's MochiKit is both simple and good.
[12:25]  <tibbs> So: proposed action plan:
[12:25]  <abadger1999> Err.. tibbs's explanation is better :-)
[12:25]  <tibbs> Investigate what javascript compressors we have in Fedora.
[12:25]  <tibbs> Look at a couple of non-mootools javascript libraries.  (I have another one needed for zoneminder.)
[12:26]  <spot> seems like a good plan to me.
[12:26]  <tibbs> spot: Are the GPL-related issues worth looking into?
[12:26]  <spot> i'll leave this on the agenda, and we'll revisit it next time
[12:26]  <spot> tibbs: only if we have a specific case
[12:26]  <spot> because i will have to take it to the lawyers for interpretation
[12:27]  <abadger1999> tibbs: Sounds good.  Do we want to bring any of this up with any upstreams?  Or just look at it from the "How easy is it to package" side?
[12:27]  <tibbs> I think it would be better to have something more fleshed out first.
[12:27]  <abadger1999> Okay.
[12:27]  <spot> Alright. Next item: http://fedoraproject.org/wiki/DennisGilmore/SugarActivityGuidelines
[12:28]  <spot> This has changes for multilib and directory naming
[12:29]  <tibbs> Is this the correct diff from last time:
[12:29]  <tibbs> http://fedoraproject.org/wiki/DennisGilmore/SugarActivityGuidelines?action=diff&rev2=8&rev1=4
[12:29]  <tibbs> ?
[12:29]  <spot> yes
[12:30]  <spot> This seems pretty straightforward to me
[12:31]  <spot> (and not just because i helped Dennis clean it up)
[12:31]  <tibbs> This looks much better to me, although it's hard to evaluate the "Architecture-specific Activities" bit without actually seeing an example.
[12:31]  <spot> tibbs: SimCity is an example
[12:31]  <tibbs> I'm hoping "as appropriate" is pretty obvious.
[12:31]  <spot> they have python code that launches it as a sugar activity
[12:31]  <spot> there is a /usr/bin/SimCity
[12:32]  <spot> as appopriate in the context of the other Packaging Guidelines
[12:32]  <tibbs> Ah, OK.
[12:32]  <rdieter> the new draft looks like a winner to me.
[12:32]  <tibbs> +1
[12:32]  <spot> +1
[12:32]  <spot> ok guys, lets vote on it.
[12:33]  <rdieter> +1
[12:33]  <hansg> +1
[12:33]  <SmootherFrOgZ> +1
[12:33]  <delero> +1
[12:33]  <abadger1999> +1
[12:33]  <spot> Rathann, racor: feel free to vote if you would like it to be on the record.
[12:33]  <spot> but with a +7, it passes
[12:33]  <spot> for the new guys, anything +5 passes
[12:34]  <hansg> and -1 does not substract, so there is no _Real_ difference between 0 and -1
[12:34]  <spot> ok, next item: http://fedoraproject.org/wiki/PackagingDrafts/StaticLibraryPolicy
[12:34]  <hansg> but where possible we try to achieve no -1's
[12:34]  <hansg> Ah yes
[12:34]  <spot> i reworked this somewhat this morning, there is no longer the concept of "static-noshared"
[12:35]  <spot> after thinking about that, it doesn't make any sense.
[12:35]  <hansg> I've got a very interesting package with regard to this, to so called exception to the rule I guess
[12:35]  <hansg> I'm happy to pass this if allegro gets excepted
[12:35]  <spot> hansg: what's allegro's situation?
[12:36]  * rdieter likes the amended static policy better.
[12:36]  <spot> (one of those apostrophes was unnecessary)
[12:36]  <hansg> I was just going to ask if anyone wanted to know the long story, but spot beat me to it
[12:37]  <hansg> Okay, so here it goes, allegro is a shared libary, with some asm code used on various platforms
[12:37]  <hansg> this asm code however is not PIC, which is a no go on anything but i386 and frowned up on i386
[12:37]  <hansg> upstream has fixed this in an interesting way
[12:38]  <hansg> the non PIC asm code is in a static lib called liballeg_unsharable.a
[12:38]  <Rathann> so... what's the difference between current guideline and the new draft?
[12:38]  * Rathann can't find any
[12:38]  <spot> Rathann: almost nothing. its just a clarification, really.
[12:38]  <hansg> and all the applications which link to allegro use the following (allegro-config --libs)
[12:38]  <hansg> -Wl,--export-dynamic -lalleg-4.2.2 -lalleg_unsharable
[12:39]  <Kevin_Kofler> Surely the right solution there is to fix the ASM?
[12:39]  <Rathann> surely :)
[12:39]  <Kevin_Kofler> Many libs manage to make PIC ASM.
[12:39]  <hansg> So the non pic code gets put in the binary not in the .so and then exported to the shared lib
[12:39]  <spot> hansg: so, the scenario is that the shared library is useless without the static?
[12:39]  <hansg> yes
[12:39]  <Rathann> making it pic compatible might make it slower though
[12:39]  <hansg> spot yes that is
[12:39]  <spot> wow, thats a hell of a corner case.
[12:39]  <hansg> Kevin_Kofler, I'm happy to take paches for this and send them upstream
[12:40]  <spot> could you put it in -static, and then have base depend on -static ?
[12:40]  <hansg> yes, which I don't think we need to cover in the guidelines, as there will always be exceptions, lets just grant an exception to allegro, keep both the .a and .so  symlink in -devel and be done with it
[12:41]  <hansg> spot, not usefull, as the .a isn't needed to run the applications, as its already linked into the applications
[12:41]  <spot> eh, ok.
[12:41]  <spot> i'm alright with that being a permitted exception
[12:41]  <spot> given how unusual it is.
[12:41]  <abadger1999> So... wouldn't we still want to know that a static library is being linked here?
[12:42]  * rdieter was wondering that too
[12:42]  <spot> thats a valid point.
[12:42]  <tibbs> I did think the whole point of the guideline was to make it easy to find what linked against a static lib.
[12:42]  <delero> if the static lib is part of the devel package also ?
[12:42]  <hansg> yes but thats easy if a security bug is ever found in allegro's static code we can just query for anything depending on the .so as that will have the static code linked in
[12:42]  <hansg> as the .so is useless (unresolved symbols) otherwise
[12:43]  <rdieter> hansg: ok, since it's exceptional already. :)
[12:43]  <spot> ok, lets vote on the draft as is:
[12:43]  <spot> +1
[12:43]  <delero> +1
[12:43]  <hansg> +1
[12:44]  <SmootherFrOgZ> +1
[12:44]  <Rathann> +1
[12:44]  <tibbs> Let me be clear:
[12:44]  <tibbs> What's gone here is the weird contradictory exception about being able to BR *-devel if there are only static libaries present?
[12:44]  <spot> tibbs: yes.
[12:44]  <tibbs> +1
[12:45]  <rdieter> +1
[12:45]  <rdieter> and anything static linking needs: BR: *-static ?
[12:46]  * abadger1999 would also like to know what rdieter asked
[12:46]  <rdieter> reading, looks like the answer is yes.
[12:46]  <spot> yes.
[12:47]  <tibbs> What we lose is the "auto-switch" if a package suddenly starts providing dynamic libs.
[12:47]  <spot> yes, but we gain in tracking
[12:47]  <abadger1999> So to use allegro as an example, apps linking against allegro will BuildRequire: allegro-static
[12:47]  <spot> which is infinitely more important
[12:47]  <tibbs> That's such a corner case that it's worth the guideline clarity to get rid of it.
[12:47]  <abadger1999> But we're making an exception so the static library can go in -devel?
[12:48]  <hansg> Erm, lets not use allegro as an example please
[12:48]  <spot> allegro is a bad example
[12:48]  <abadger1999> Well, the exception is being written in.
[12:48]  <spot> abadger1999: not into the guidelines it isn't.
[12:48]  <abadger1999> err.... That's how we've done evey other guiedeline exception.
[12:49]  <spot> well, we could write it in.
[12:49]  <abadger1999> spec file naming with gcc, for instance.
[12:49]  <spot> if i was going to do it, this is what I would say:
[12:50]  <spot> "If (and only if) a packages shared libraries require static libraries to be functional, the static libraries can be included in the -devel subpackage. The devel subpackage must provide -static, and packages dependent on it must BR -static.
[12:50]  <abadger1999> Sounds good.
[12:50]  <abadger1999> +1
[12:51]  <hansg> Can't we just document the exception in the meeting Minutes, if we are going to put every exception ever granted into the guidelines things will become messy
[12:51]  <spot> lets get a round of votes on the "allegro" exception?
[12:51]  <abadger1999> hansg: The idea is not to have exceptions.
[12:51]  <Rathann> sounds OK
[12:51]  <Rathann> +1
[12:51]  <spot> +1 from me
[12:52]  <tibbs> I have no problems with excepting allegro.  +1
[12:52]  <hansg> I don't like it, why should the packages BR the -static, what if the code ever gets pic-ified (I'm counting on a patch from Kevin for this soon)
[12:52]  <abadger1999> When we do have exceptions, the reasons are listed so that we have a basis to adjust the guidelines when things become unwieldy.
[12:52]  <spot> hansg: then they fix their BR.
[12:52]  <spot> hansg: think of this from rel-eng's perspective
[12:52]  <hansg> This would mean changing the BR's of 29 packages now and changing them back if this ever changes
[12:53]  <abadger1999> hansg: That's what tibbs and spot were mentioning earlier:
[12:53]  <abadger1999> (10:47:23 AM) tibbs: What we lose is the "auto-switch" if a package suddenly starts providing dynamic libs.
[12:53]  <abadger1999> (10:47:34 AM) spot: yes, but we gain in tracking
[12:53]  <hansg> Thats a lot of needless churn
[12:53]  <spot> they'd like to know every package which uses static libs
[12:53]  <Kevin_Kofler> Speaking of the GCC specfile naming exception, why does GCC have a gcc43.spec now when the guidelines clearly stated that the next version should move to just gcc.spec?
[12:53]  * hansg is starting to with I've just kept quiet about this
[12:53]  <Kevin_Kofler> I made that point in the merge review and got entirely ignored.
[12:53]  <tibbs> "a lot"?
[12:53]  <hansg> s/with/wish/
[12:53]  <tibbs> This happens, what, once every couple of years?
[12:53]  <spot> Kevin_Kofler: i'll poke jakub.
[12:54]  <hansg> What guideline changes, no they seem to happen all the time
[12:54]  <tibbs> No, a package suddenly providing dynamic libraries when it only provided static ones before.
[12:54]  <hansg> tibbs that not the case here
[12:55]  <spot> hansg: i do think it is important that we track static library use, even in this weird hybrid case.
[12:55]  <spot> hansg: you can BR both if you'd like
[12:55]  <hansg> Yes and I think its important we support every piece of hardware out there, but there is only so little time and so much todo
[12:56]  <hansg> I'm fine with this if someone else will fix all the allegro packages
[12:56]  <spot> hansg: i will do it then. :)
[12:56]  <hansg> ok +!
[12:56]  <hansg> make that +1 even
[12:56]  <spot> alright, i think we have enough +1s for this to be passed
[12:57]  <spot> i'll add the exception before FESCo looks at it
[12:57]  <spot> that is all i had for the agenda today
[12:57]  <spot> the floor is open for other issues
[12:57]  <rdieter> +1 here too
[12:58]  <spot> if you have no additional issues for today, please say "no".
[12:58]  <spot> so i can close this up and go eat lunch. :)
[12:58]  <hansg> no
[12:58]  <tibbs> I can't recall if we have new guidelines this week.
[12:58]  <rdieter> no
[12:58]  * Rathann has nothing
[12:58]  <hansg> or rather yes, meeting time?
[12:58]  <abadger1999> no
[12:58]  <hansg> since spot's remark queued me that DST has hit the US now too
[12:59]  <spot> hansg: ah, yes. i will send out an email asking for people to fill out a "good time for meeting" matrix
[12:59]  <hansg> I'm fine with the current time, but maybe some others want to it changed?
[12:59]  <spot> we'll see if we can come up with "better" options
[12:59]  <hansg> ok
[12:59]  <spot> no more from me
[12:59]  <tibbs> Ahh,  NoBitsInSrv and the GCJ update were ratified last week.
[13:00]  <spot> tibbs: thats right. i'll tackle the writeups while i'm poking things today
[13:00]  <tibbs> OK.  Nothing else from me.
[13:00]  <spot> alrighty. lunch time for me, this meeting is done!
[13:00]  <spot> thanks everyone
[13:01]  <tibbs> Next meeting in two weeks, 2008.05.06
Retrieved from "https://fedoraproject.org/w/index.php?title=Packaging:Minutes20080422&oldid=66595"