From Fedora Project Wiki

Fedora Packaging Committee Meeting 2008-12-09

Present

  • DominikMierzejewski (Rathann)
  • HansdeGoede (hansg)
  • JasonTibbitts (ubertibbs)
  • RalfCorsepius (racor)
  • RexDieter (rdieter)
  • TomCallaway (spot)
  • ToshioKuratomi (abadger1999)

Regrets

  • DenisLeroy (delero)
  • XavierLamien (SmootherFrOgZ)

Votes

The following proposals were accepted by the committee:

  • Codifying adherence to FHS, with exceptions for libexec and /usr/target for cross compilers
    • There is no draft; the details were worked out during the meeting.

Other Discussions

  • There was additional chatting about properly handling javascript.

IRC Logs

hansg has joined this channel (n=hans@ip32-174-211-87.adsl2.static.versatel.nl). 11:03
* rdieter owes svahl another adult beverage of choice 11:04
hansg Hi all, I'm present for the fpc meeting. 11:04
* spot looks around for FPC members 11:04
f13 I'm lurking today 11:04
* spot sees abadger1999, tibbs|h, rdieter, Rathann 11:06
spot and hansg, of course. ;) 11:06
abadger1999 I'm here. 11:06
* rdieter puts fpc hat on 11:06
Rathann present 11:06
hansg Hi all, sorry for all the missed meetings, my schedule just does not seem to align properly with the fpc meetings 11:07
spot ubertibbs: ping 11:07
ubertibbs Yep. 11:07
racor has joined this channel (n=rc040203@HSI-KBW-078-043-127-065.hsi4.kabel-badenwuerttemberg.de). 11:07
spot there's racor 11:07
ubertibbs Sorry, just had to get someone out of my office. 11:07
abadger1999 heh 11:07
racor yep, I am here ... at least for the next couple of minutes ;) 11:08
spot okay, lets get the easy one out of the way first 11:08
spot http://overholt.fedorapeople.org/EclipsePlugins.diff 11:08
Topicubertibbs sets the channel topic to "Packaging Committee Meeting". 11:08
spot basically, andrew overholt asked for changes to the eclipse guidelines to reflect the changes in eclipse 3.4 11:08
ubertibbs This is simply necessary to adapt to changes in the underlying software (and to fix a couple of typos); I think we should just do it. 11:09
spot ubertibbs: yep. 11:09
spot +1 from me 11:09
rdieter +1 11:09
abadger1999 +1 11:09
racor +1 11:09
ubertibbs +1 11:10
spot okay, thats +5 11:10
Rathann +1 11:10
spot next item: http://fedoraproject.org/wiki/PackagingDrafts/RubyGem_with_C_code 11:10
spot mtasaka made a new draft at the bottom of that page which is a lot cleaner 11:10
hansg +1 11:11
hansg That +1 is for the eclipse changes, man you are all fast 11:11
spot under "Revised proposition" 11:11
spot for me, this revised proposition is a lot clearer and simpler 11:12
ubertibbs That whole thing is confusing. 11:13
ubertibbs Are we only considering the part between "Revised proposition" and "Note"? 11:13
spot ubertibbs: and the example 11:13
Rathann it says [SOLVED] but I don't see a clear solution to "Installed C Codes" 11:13
spot hmm, i think this may make things a bit simpler 11:16
spot https://fedoraproject.org/wiki/PackagingDrafts/RubyGem_with_C_code_spot 11:16
spot those would be the guideline changes 11:16
* hansg thinks we need to tell them just to fix the gem buildsystem, or hack around it 11:16
abadger1999 Rathann: I think that's here: " Installed C codes (usually under %{geminstdir}/etc) may be removed even if gem contents %{gemname} reports that installed C codes should be found there. " 11:17
hansg Installing under builddir so as to avoid having buildroot coded into the binaries is completely fscked up, we want neither the buildroot nor the builddir encoded into the binaries !!! 11:17
Rathann hansg: +1 11:17
ubertibbs I have to agree. 11:18
ubertibbs I mean, we could just build normally and then call sed on the binaries to pass the check if that's all we care about. 11:18
warren has joined this channel (n=warren@redhat/wombat/warren). 11:18
Rathann and what's with the compilation-on-install? 11:18
ubertibbs The bottom line is that we're dealing with a broken system here. How do we address that? 11:19
* hansg votes for sending this back to the drawing board 11:19
spot also, we have gems in Fedora right now 11:19
hansg ubertibbs, patch the hell out of it until it does what we want 11:19
spot so presumably, things are worse than this in the current guidelines 11:19
ubertibbs We have plenty of gems, but how many of them have compiled C code in them? 11:19
hansg or even better explain very patiently and clearly to upstream and ask them to add a switch which does what we want ? 11:19
ubertibbs There's no question for regular gems that contain only Ruby code. 11:20
Rathann I guess we could approve it as a temporary workaround of the current problems 11:20
Rathann but only if the maintainer promises to work with upstream to resolve these problems 11:20
ubertibbs And another question: should the check that all of this hacks around simply be disabled? 11:20
hansg Rathann, small +1 (its just so d*mn ugly) 11:20
ubertibbs I mean, what are we working around here? 11:20
ubertibbs The produced binaries include the buildroot as a string somewhere. Is this actually something we care about? 11:21
hansg ubertibbs, we are working around a check, which checks that no compilation was done during %install, something which can be very bad when there is no DESTDIR, and thus we redefine PREFIX to get installed to the right place 11:21
ubertibbs Yes, the rpm check is there to catch potential breakage. But is there actual breakage in this case? 11:21
ubertibbs So is the point of this to work around the check, or is is to force the broken build system to do its building in %build instead of %install? 11:22
hansg ubertibbs, it may happen to just work here, but its *wrong wrong wrong* and the debuginfo will be completely fscked up because of this 11:23
ubertibbs Because honestly the included example doesn't look all that bad to me. 11:23
* Rathann has no idea about ruby and its gems 11:23
spot no, i think this is because the "gem" command embeds the install path passed to it in compiled libraries 11:23
spot if i run: gem install --local --install-dir %{buildroot}%{gemdir 11:23
spot then "%{buildroot}%{gemdir}" is going to get embedded into libraries 11:24
spot whereas, if i run: gem install --local --install-dir ./%{gemdir} 11:24
hansg spot, so you think that the source file paths in the debuginfo will be right? 11:24
spot hansg: i have no idea, but again, i'm not sure if the debuginfo is useful anyways for ruby gems 11:24
spot having the %{buildroot} embedded in C libraries is obviously bad 11:25
hansg spot, well if they have native code, it might be useful 11:25
spot hansg: only if a debugger can parse it sanely 11:25
hansg hmm, it seems we are not alone with this problem, see: http://pkg-ruby-extras.alioth.debian.org/rubygems.html 11:27
hansg and: http://pkg-ruby-extras.alioth.debian.org/upstream-devs.html 11:27
ubertibbs So, honestly, looking at the provided example spec, I don't see anything stomach churning. 11:27
spot yeah. it is a hack, but its not the worst hack ever. 11:28
hansg I think we should ask the Fedora ruby guys to team up with the debian ruby guys and try to get this improved upstream 11:28
spot hansg: yes, but i'd also like to let them document this interim workaround 11:28
hansg I can live with this, under the condition that some serous attempts are made to remedy this properly 11:29
Rathann well, as long as the final result is sane I'm not against this 11:29
abadger1999 ubertibbs: +1 11:29
ubertibbs I don't know how we can put conditions on a guideline like that. 11:29
Rathann although I find it odd that passing install-dir relative to current dir matters somehow 11:30
ubertibbs Now, what I would really like to see is a package that does this, so we can look at the result and make sure it is actually sane. 11:30
spot i think the best we can do is to vote on this and request that the ruby folks (mamoru and david lutterkort) try to get this fixed upstream 11:30
Rathann ubertibbs: +1, I too would like to have a testable src.rpm 11:31
abadger1999 lutter owns the rubygem package as well. 11:31
spot we can ask for an example SRPM 11:31
ubertibbs So, I hate to make them go through the cycle again. 11:31
spot as do i, but if you guys are uncomfortable with the draft as is... 11:32
ubertibbs Based on what I can see, I can vote for this but my concern is that we approve it and then rpm goes and does something bizarre with it. 11:32
spot fwiw, i'm +1 on this, with the request to fix this properly in the gem install command 11:32
hansg +1 (also with the request to fix this properly in the gem install command) 11:33
abadger1999 I'm willing to vote +1. For a hack it's pretty clean and it's an improvement on where we are today. 11:33
rdieter +1 (ditto) 11:33
Rathann +1 as well 11:33
ubertibbs We need to ask in the future that guidelines changes come with an actual package attached so that we can look over things. 11:33
abadger1999 <nod> 11:33
ubertibbs Anyway, +1 to the proposal. 11:33
spot okay, there is +5 in there 11:34
spot it passes with the request 11:34
spot Next item: http://fedoraproject.org/wiki/PackagingDrafts/Fonts_packaging_automation 11:34
spot there are a few things in here 11:34
spot the first one is a followup from http://fedoraproject.org/wiki/PackagingDrafts/Fonts_spec_template_correction:_fontconfig_(2008-10-12)) 11:35
spot we approved it, pending upstream feedback 11:35
ubertibbs Personally I have no real problem with magicalness in specs and hiding things behind macros. 11:35
ubertibbs But I know that others here have disagreed in the past. 11:35
spot well, in the case of fonts, this is already happening 11:36
spot this effort is to standardize the macros 11:36
ubertibbs It isn't as if we haven't approved GHC and Java guidelines in the past after asking them to hide more things behind macros. 11:36
abadger1999 spot:agreed. The macros have already happened. 11:36
ubertibbs I do with the "set of font packages" links actually had some spec files I could look at. 11:37
hansg Fonts_packaging_automation, +1 (I'm assuming the actual macros will get vetted during the review of the package) 11:37
spot I'm +1 here as well 11:37
ubertibbs hansg: I don't think it is safe to assume that. 11:37
abadger1999 +1 11:37
hansg ubertibbs, even then I'm still +1, I don't want the fpc to go vetting each and every macro ever introduced / used 11:38
Rathann I remember reading that earlier on the mailing list, I liked it and I see my comments have been taken into account, so +1 11:38
racor -1 11:38
Rathann however I think it should be named fonts-* not fontpackages-* 11:38
* hansg wonders whats in a name 11:39
ubertibbs I'm getting blown over by the bureaucracy here. Can this whole thing be condensed to "We want to add five macros"? 11:39
racor to me, using the package is a massive mistake 11:39
spot ubertibbs: and take into account the avail.d/ changes we saw before 11:39
racor ubertibbs: Yes and move it to fedora-rpm-config 11:40
ubertibbs racor: Can you articulate your objections? I would really like to hear them, but I'm concerned that IRC is not a good medium for that. 11:40
racor I am objecting the macros 11:40
ubertibbs Where do you actually see the macros? 11:41
racor once a macro is in, you can hardly ever get rid of them 11:41
ubertibbs It's like this proposal is a long-winded document but doesn't actually include the changes they want to make. 11:41
racor they are part of the src.rpm 11:41
* f13 wonders what racor suggests as an alternative 11:41
ubertibbs I guess I'll go unpack it now. They should be in the actual proposal. 11:42
f13 mass cut/paste ? 11:42
spot http://fpaste.org/paste/143 11:43
Rathann f13: python and perl package specfiles define python and perl paths themselves, so there is a precedent 11:43
ubertibbs racor: Are you objecting to things like %_fontbasedir %{_datadir}/fonts 11:43
racor ubertibbs: yes. 11:43
ubertibbs Thinking instead that packages should just use %{_datadir}/fonts if that's what they mean? 11:43
f13 Rathann: precedent, or lazyness? 11:43
spot f13: precedent. these macros are useful. 11:43
racor furthermore you would have to BR: fontpackages-devel in all fonts*specs 11:43
spot (well, at least the python/perl ones) 11:43
f13 spot: I meant precedent to leaving them in the top of .spec files rather than putting them in redhat-rpm-config 11:44
ubertibbs racor: Then do you object to, say, the %{_R_make_search_index} macro from the R guidelines? 11:44
Rathann well, fontbasedir seems redundant, it's used only once 11:44
spot f13: the point being that having standardized macros makes it easier for new packagers 11:44
f13 spot: I don't think you're seeing my argument. 11:44
ubertibbs Or the %ghc_preinst_script macro from the Haskell guidelines? 11:44
f13 spot: I wasn't buying the macros being in the top of python spec files as 'precedent for not having site wide macros' 11:44
Rathann f13: I meant it as a bad example :) 11:45
Rathann they should be moved out of these specs into rpm config 11:45
racor the perl macros are implemented in *-rpm-config, not in a separate package 11:45
Rathann not necessarily a separate package 11:45
spot racor: so, you'd be okay with these macros in *-rpm-config ? 11:46
racor ... and you can hardly get rid of them 11:46
Rathann well, racor has a point about not adding BR: fontpackages-devel to every font package 11:46
rdieter it's not uncommon for initial implementations to start elsewhere, and once proven, move into -rpm-config. 11:46
racor spot: no, I am against any vendor-proprietary macros. 11:46
ubertibbs I'm just trying to understand racor's objection. Is it that we shouldn't be adding macros, ever? Or that these macros don't add enough value? Or is it something else? 11:46
racor I am not opposed to upstream rpm providing macros 11:47
rdieter Rathann: that's a policy decision made by font sig, if that's what they want. 11:47
* hansg watches the clock 11:47
spot so, basically, the only thing for FPC here is whether we approve the macros and use of avail.d 11:47
Rathann rdieter: sure, if someone takes care of that, then it's fine, but I do object slightly to adding "just one line" to every font spec 11:48
rdieter Rathann: also, font sig's job, imo, to "take care of that". :) 11:48
racor rdieter: do we care about other people's ponys? 11:48
Rathann having said that, I'm still in favour of this draft 11:48
ubertibbs Personally I have no problems with adding additional macros if it makes things simpler for the packagers and makes the packages simpler to comprehend. 11:48
spot Can we do a vote? 11:49
racor spot: i this applies, you can shut down this FPC 11:49
rdieter racor: as long is they don't interfere, and play nice with other ponys. 11:49
racor it's our job to review other group's proposal. 11:49
ubertibbs And I don't think the committee as a whole does, either, because we've approved Haskell and Java and R in the past, with their macros included. 11:49
spot racor: and... we are. 11:49
racor ubertibbs ... yes, mistakes to learn from. 11:50
ubertibbs Hardly. 11:50
ubertibbs I mean, this wasn't even raised as an objection then. 11:50
ubertibbs We _asked_ them to add macros to Java and Haskell. 11:50
* f13 hasn't noticed the world ending because java packages have macros 11:51
racor ubertibbs: Did we? 11:51
Rathann spot: +1 on fonts packaging automation 11:51
ubertibbs It makes the packages reasonable instead of having 50 lines of identical shell code pasted into them. 11:51
spot +1 from me 11:51
hansg spot: +1 on fonts packaging automation 11:51
ubertibbs +1 from me. 11:51
racor -1 from me 11:51
rdieter +1 (there's good and bad uses of macros, this is an example of the good kind, imo) 11:51
ubertibbs racor: If you want the reference where we asked the Java folks to add the macros, I will dig it out for you. 11:52
spot abadger1999: would you like to vote? 11:52
abadger1999 +1 11:52
spot okay, thats 6 for and 1 against, it passes 11:52
spot we have two other items on the "todo" list for today, but i'm not sure they are ready for review yet 11:52
spot JavaScript and Python Virtual Provides 11:53
spot abadger1999: both of these are yours, i believe 11:53
abadger1999 spot: Too busy with upstream python issues. 11:53
spot abadger1999: okay, then, are there any other issues for today? 11:53
abadger1999 I owe the committee a pros and cons table for the javascript guidelines. 11:53
abadger1999 https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00074.html 11:53
abadger1999 That's an additional issue. 11:54
f13 there was the message I posted regarding review guidelines vs package guidelines 11:54
ubertibbs Yes, f13's request. 11:54
spot if no one is opposed, i can go over the review guidelines and make sure they're all expressed in the packaging guidelines 11:55
abadger1999 spot: +1 11:55
f13 i was kind of hoping some kind soul would do it so that spot or I wouldn't have to (: 11:55
spot f13: i know them well enough, it won't take me too long 11:55
ubertibbs +1 for someone else doing it. 11:55
ubertibbs I so hate working in the wiki. 11:55
spot okay, since i am not hearing opposition, i'll just tackle that 11:56
f13 ubertibbs: you should really try lmacken's vim plugin for firefox/wiki 11:56
spot as to the FHS stuff, i'm not opposed with making it a MUST that packages follow the FHS 11:56
ubertibbs f13: I used to use mozex, but it doesn't work with ff3. 11:56
spot the only thing that gives me concern is cross compilers 11:57
ubertibbs Well, remember that /spu was a mistake that has been fixed. 11:57
spot i know they need a toplevel in /usr 11:57
Rathann is FHS sane now? if so, no objections 11:57
racor spot: why? 11:57
ubertibbs And I tried to do something about cross-compilers and was flamed so much for my trouble that I gave up. 11:57
spot racor: that was what i thought, keeping in mind that i'm not an expert here 11:57
racor the spu package is simply broken. 11:57
spot racor: do cross compilers need to violate the FHS? 11:57
f13 racor: cross compilers need /usr/<target>/ don't they? 11:57
hansg f13, that is preferred way of doing things, yes 11:58
racor spot,f13: Right, the need $exec_prefix/<target> 11:58
f13 is that allowed by the FHS ? 11:58
QuitSonar_Gal has left this server (Read error: 110 (Connection timed out)). 11:58
abadger1999 spot, racor: Is the crosscompiler location specified in the GNU coding standard? 11:58
racor f13, no, but it's common practice ever since GCC is around 11:58
ubertibbs racor: So when spot said the same thing as you just said, you replied "why?". 11:58
* abadger1999 knows that libexecdir is. 11:58
hansg f13, AFAIK no, but it is how the whole world does it 11:58
f13 so this is exactly what spot was asking about 11:59
ubertibbs It's no wonder why people are confused. 11:59
spot so, i don't think the FHS specifies where cross toolchains should go 11:59
f13 cross compilers don't adhere to the FHS, so that's a concern if we were to make FHS mandatory. 11:59
Rathann f13: we could make it mandatory except for cross-compilers 11:59
ubertibbs "As exceptions..... libexec.... cross compilers..." 11:59
f13 (or more correctly the FHS doesn't adhere to cross compilers) 11:59
racor spot, f13: the why was aiming at the spu toolchain. it is badly packaged 12:00
f13 racor: spu was the recent example, regardless of /spu, it also had /usr/spu/ 12:00
spot really, this boils down to a lack of guidelines for how to package cross toolchains 12:00
racor there is no need for /spu, GCC however needs /usr/spu 12:00
f13 ubertibbs: clearly all our guidelines must have 2 listed exceptions to them. Lets make /that/ a guideline, with exceptions (: 12:01
abadger1999 Looks like crosscompiler location is not specified in GNU standards. 12:01
racor that said, /usr/<target> is the only case where GCC-cross toolchains deviate from the FHS. 12:01
f13 racor: please ignore the "/spu" part of the question. spot was mostly concentrating on /usr/spu which is common across all cross compilers we have (/usr/<target>) 12:01
ubertibbs Everyone knows and agrees that /spu was a mistake caused by a macro that somehow was undefined. It was fixed immediately after it was brought up. 12:01
spot okay, so we could make this a must and add the exception for the /usr/<target> for cross toolchains? 12:01
racor spot: OK with me. 12:02
spot are there any other places where enforcing the FHS strictly would cause us problems? 12:02
abadger1999 "with exceptions for libexecdir (specified in the GNU Coding Standards [LINK]) and /usr/target for crosscompilers" 12:02
abadger1999 http://www.gnu.org/prep/standards/standards.html#Directory-Variables 12:02
hansg spot, +1 12:02
ubertibbs I'm sure there are other problems, but we should simply address them when they come up. 12:03
racor this of course should not invalidate attempts to make GCC better compliant to the FHS. 12:03
spot abadger1999: looks good to me. 12:03
abadger1999 +1 from me :-) 12:03
racor +1 12:03
Rathann +1 12:03
spot +1 12:03
rdieter +1 12:04
spot ubertibbs: would you like to chime in? 12:04
ubertibbs +1 12:04
ubertibbs sorry 12:04
spot okay, thats +5 easily 12:04
spot any other items? 12:04
spot none from me 12:04
Rathann so javascript and python are postponed? 12:05
spot Rathann: yes 12:05
Rathann js looks fine to me though 12:05
Rathann we've already discussed it too 12:05
abadger1999 Rathann: Yeah... I've been running across problems with my own draft. 12:05
Rathann ah 12:06
hansg For those interested in cross compiler guidelines the embedded SIG (which is sort of dead atm) has a blurb here: http://fedoraproject.org/wiki/Extras/SIGs/Embedded/CrossCompiling 12:06
abadger1999 Rathann: I want to change javascript to be more like static libraries. 12:06
Rathann ok then 12:06
ubertibbs It's more along the lines of it not really being reasonable to do it in some other way. 12:06
abadger1999 But that has the usual static library issues so it needs evaluation. 12:06
hansg The <exex-prefix>/<target> is specified in gcc's INSTALL document 12:06
Rathann abadger1999: not more like java .jars? 12:06
ubertibbs BTW, I just approved a puthon package that includes some portion of jquery. Maybe I shouldn't have done that; I'm not really sure. 12:07
abadger1999 Rathann: I'm only passingly familiar with .jars What do you see as a parallel? 12:07
abadger1999 ubertibbs: <nod> Until we get JavaScript Guidelines, that's probably what we should do. We'll definitely want to clean those up after wards, though. 12:08
* hansg has got to go now 12:09
Rathann when not used via http, both jars and js have be put into path or symlinked to be usable by an application 12:09
hansg Next meeting same time ? I still really would like to see a different time. 12:10
hansg Bye all/ 12:10
Rathann but they're not "linked in" as is the case with static libs 12:10
Rathann bye hansg 12:10
Rathann abadger1999: ^ 12:10
abadger1999 So js is a bit more involved. Because it is almost always served over http, having tons of little files creates a huge latency. 12:10
spot feel free to keep chatting guys, but i'm calling the meeting 12:11
Rathann true 12:11
abadger1999 But to organize your code you want to have lots of little files. 12:11
Rathann thanks spot :) 12:11
abadger1999 Thanks spot! 12:11
abadger1999 So with dojo, I discovered that they distribute a tarball with tons of individual files, a way to specify dependencies between them, and a script to "compile" them into a single file. 12:12
Rathann ah 12:12
Rathann neat, but do we really want to do that? 12:12
abadger1999 heh. Not sure :-) 12:12
abadger1999 If we did, then it would be like static libraries. 12:13
Rathann yes 12:13
nim-nim all: thanks for approving the fonts stuff 12:13
abadger1999 If we don't, applications will be very slow by default. 12:13
Rathann abadger1999: what's the slowdown? 10%? 50%? 12:13
abadger1999 Rathann: I found it depends on the http server. For a python app using CherryPy, it was seconds vs minutes. 12:14
abadger1999 Rathann: When I switched it to apache, it was still seconds vs over a minute. 12:15
Rathann I'm thinking about some sort of caching/preprocessing, i.e. build one file out of all the dependent js files but rebuild it if any of them gets updated 12:16
abadger1999 <nod> You mean dynamically? 12:16
Rathann I guess 12:16
abadger1999 mod_javascript :-) 12:16
Rathann heh 12:16
Rathann just an idea 12:17
Rathann all right, I have to go shop for food 12:17
Rathann later folks 12:18
abadger1999 yeah. I think it's a good idea but there's no upstream project to do it ATM... We'd have to devote manhours to make it happen. 12:18
abadger1999 Rathann: Later! 12:18
Rathann has left this channel ("Leaving."). 12:18
Retrieved from "https://fedoraproject.org/w/index.php?title=Packaging:Minutes/20081209&oldid=66517"