From Fedora Project Wiki

The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

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"