From Fedora Project Wiki

Fedora Packaging Committee Meeting 2009-01-20

Present

  • Denis Leroy (delero)
  • Dominik Mierzejewski (Rathann)
  • Hans de Goede (hansg)
  • Jason Tibbitts (tibbs)
  • Ralf Corsepius (racor)
  • Rex Dieter (rdieter)
  • Tom Callaway (spot)
  • Toshio Kuratomi (abadger1999)

Regrets

  • Xavier Lamien (SmootherFrOgZ)

Writeups

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

Votes

The following proposals are submitted to FESCo for approval:

IRC Logs

*** spot sets the channel topic to "Fedora Packaging Committee Meeting - https://fedoraproject.org/wiki/PackagingDrafts/DraftsTodo". 11:05
--> racor has joined this channel (n=rc040203@HSI-KBW-078-043-127-065.hsi4.kabel-badenwuerttemberg.de). 11:05
spot i see hans, me, and racor 11:06
* rdieter puts on fpc hat 11:06
spot abadger19991, tibbs, SmootherFrOgZ? 11:06
tibbs Yep. 11:06
tibbs First day of the semester; very busy here at work. 11:07
--> Rathann has joined this channel (n=rathann@fedora/rathann). 11:07
Rathann hi guys, sorry for being late 11:07
Rathann I just got home 11:07
spot no worries 11:07
* spot apologizes in advance, i have the US presidential inauguration on in the background 11:08
spot first draft for review: https://fedoraproject.org/wiki/PackagingDrafts/ExplicitRequires 11:08
Rathann +1 for ExplicitRequires 11:09
hansg What is with the "non-superfluous or versioned explicit" language 11:09
hansg If I read it correctly it states any explicit requires should have a comment? 11:09
spot hansg: that's what it says 11:10
tibbs That seems a bit excessive. 11:10
tibbs I mean, rpm simply doesn't generate automatic dependencies for a lot of things. 11:10
spot i can make that a should 11:10
hansg It says that "non-superfluous or versioned explicit" should have a comment, but since superfluous Requires should be removed that means all Requires should have a comment ? 11:10
spot yeah, that doesn't make much sense to be a must 11:11
spot i'll make it a should 11:11
hansg To be clear I'm not arguing against that per se, but the language seems more complicated then necessary 11:11
hansg It could be just "Any explicit requires should have a comment" 11:11
spot okay, it is no longer a must. :) 11:11
tibbs Even then, I'd hate to see an argument about comments on dependencies for some python or ruby package review. 11:11
spot hansg: i like that 11:12
tibbs On some level, this is common sense. "Let RPM figure out what it can, fill in any dependencies it doesn't handle automatically." 11:13
hansg Although I must agree with tibbs that it seems a bit excessive (hence the should I understand, but will reviewers understand) ? 11:13
hansg For example any package which installs an icon under the freedesktop icon hierarchy has a "Requires: hicolor-icon-theme" 11:14
--> delero has joined this channel (n=denis@nat/sun/x-057c9b84b5d7f2a0). 11:14
* spot made some of the language simplification changes 11:14
delero sorry for being late 11:14
hansg I think putting a comment next to that in all such spec files will not help readability, but rather hurt it 11:14
Rathann tibbs: python/ruby/whatever requires should ideally be discovered automagically, like perl 11:14
tibbs Oh, sure, but they aren't. 11:14
tibbs We live with the RPM we have, remember. 11:14
Rathann indeed 11:15
hansg This is not the RPM you are looking for :) 11:15
Rathann delero: we're discussing https://fedoraproject.org/wiki/PackagingDrafts/ExplicitRequires 11:15
tibbs Maybe the python stuff us coming, but does it work for ruby or haskell or lua or whatever is coming up next? 11:15
delero rathann: thanks 11:15
rdieter this discussion tickles a memory... isn't this similar in spirit to the existing directory ownership guidelines? 11:16
racor I think, in the last sentence, the "explicit versioned dependency" should be changed into "explicit dependency" 11:16
spot racor: yes, i agree. (changes it) 11:16
tibbs Are versioned dependencies really special to this guideline? 11:16
racor tibbs, spot: IMO, no. 11:17
tibbs I mean, there is often the issue of requires: glibc > 2.0 or somesuch. The version here is obviously superfluous. 11:18
tibbs But that's not what this guideline is about. 11:18
spot well, if it helps reviewers ask the question of whether that Requires: glibc > 2.0 is necessary, i think this has value 11:19
spot (or Requires: glibc) 11:19
delero +1 from me overall 11:20
spot +1 from me as well 11:20
delero is there a tool that will automatically prune out unnecessary Rs given a list ? 11:20
delero (i.e. where one of the R already brings in the other one, like gnome,glib) 11:21
spot delero: not that I know of, but it would be useful (and I suspect, not terribly difficult to write) 11:21
racor IMO, the primary problem is explicit "package" deps tending to cause broken deps and installation bloat 11:21
racor +1 11:21
rdieter +1 11:21
tibbs spot: I'm concerned that the guideline doesn't actually talk about the situation of versioned dependencies becoming out of date. 11:21
tibbs It just says "out-of-date" but doesn't really define what it means. 11:22
tibbs I know we have a general "present in the last two releases" rule, but it might be worthwhile to state that explicitly. 11:22
Rathann good point tibbs 11:22
spot okay, I can do that 11:23
hansg Suggestion could we change the second part of the review guidelines modification from: "(2) ensure that any explicit Requires are explained with comments in the spec file." to "(2) ensure that any *non standard * explicit Requires are explained with comments in the spec file." 11:24
abadger19991 here now 11:24
hansg The * * denote the change 11:24
spot i'm not opposed to that change. what does everyone else think? 11:24
hansg Otherwise I'm afraid new inexperience reviewers are going to ask for comments for each and every Requires 11:25
tibbs Does "ensure" sort of imply "must" to anyone? 11:25
Rathann hansg: "non-standard" as in: not explicitely mentioned in packaging guidelines? 11:25
hansg I know non standard is vague, but it atleast hints that not each and every Requires needs a comment 11:25
hansg Rathann, yes and no that sort of covers it but not completely, Directory ownership requires are in the guidelines, but i'm sure there are other very straightforward Requires uses which are not 11:26
spot tibbs: how does this sound as an added sentence: "For example, Fedora packages are only required to retain historical provides for two full release cycles." 11:26
racor tibbs: yes, to me "ensure" is a synonym to "must" 11:27
tibbs spot: Yes, I agree. 11:27
hansg racor, tibbs to me too 11:27
abadger19991 I'd -1 the whole of section (2). 11:27
delero i'd add a comment to make it clear this only applies to Requires, not BuildRequires 11:28
tibbs How about "please consider adding comments to dependencies which are nonobvious"? 11:29
tibbs Hell, "please comment anything in your spec which is nonobvious". 11:29
hansg abadger19991, that might actually be a good idea, the need to add comments in a non standard situation is something which applies to any non standard situation, so if we just leave in (1) for the review guidelines and adjust the package guidelines addition to match this (ie no talk about comments) I think it will be better 11:29
tibbs But then we get to argue about obviousness. 11:29
*** abadger19991 is now known as abadger1999. 11:29
hansg tibbs, exactly we need a "please comment anything in your spec which is nonobvious". This does not belong (*here*) (as in no in a piece about Requires( 11:30
spot how about: "SHOULD: Reviewer should examine an RPM package's list of dependencies and recommend that any unnecessary explicit Requires within the spec file are removed." 11:30
rdieter my obviousness bikeshed is pale blue 11:30
hansg spot: "SHOULD: Reviewer should examine an RPM package's list of dependencies and any unnecessary explicit Requires found must be removed." 11:30
spot i don't like putting "must" in a SHOULD. 11:31
hansg As in the checking the requires is optional, but if the reviewer goes through the trouble to do it, the submitter must fix it ? 11:31
abadger1999 can we make it a MUST without the comment section? 11:31
spot we could do it as a MUST and a SHOULD 11:32
hansg Spot, But I'm fine with your original one too 11:32
hansg spot MUST and SHOULD ? 11:32
hansg I'm ok with making this a MUST without the comment thingie 11:32
spot MUST: Reviewer must examine an RPM package's list of dependencies and any unnecessary explicit Requires found must be removed. 11:32
hansg spot +1 11:32
spot SHOULD: Any explicit Requires should have a comment which describes why they are necessary. 11:33
hansg spot -1 11:33
spot i think there is some value in the comments, we should encourage them, but not require them. 11:33
spot if someone picks up a retired package, they may not know why there is a versioned Requires. 11:33
hansg I think we need to add something like: "SHOULD: anything in the spec file which is nonobvious should have a comment explaining it" 11:34
spot SHOULD: Anything in the spec file which is nonobvious (such as explicit Requires) should have a comment explaining it 11:34
hansg Erm, sorry, but no. explicit requires can actually be very obvious 11:35
spot such as "some explicit Requires" 11:35
hansg How about: SHOULD: Any versioned Requires should have a comment explaining it 11:35
abadger1999 If this is a top level SHOULD, it shouldn't mention Requires.... 11:36
spot no, because that doesn't cover someone who really does need Requires: glibc for some horrible reason 11:36
hansg I could live with that (change from Spot's proposal I -1 -ed is the adding of versioned) 11:36
abadger1999 We can have a sentence in the longer explanation in the Requires guideline saying, Remember the "Should: Comments!" guideline 11:36
spot abadger1999: yeah, okay, let me draft that up a bit... 11:37
hansg spot, if someone needs something for some horrible reason that is plain non obvious and thus needs a comment independend on wether it is a Requires or some !@%$ ugly shell or whatever 11:37
spot what would some other examples of non-obvious items in a spec file be? 11:40
tibbs I'm always requesting that things be commented in specfiles, but I can't think of a single example off the top of my head. 11:41
abadger1999 FHS violations 11:41
tibbs Maybe things like Obsoletes:, complex licensing issues. 11:41
tibbs When you run sed over libtool to filter rpath or pass -Wl,as-needed. 11:42
abadger1999 Changes to optflags 11:43
hansg sed -ing the hell out of Makefile(s) / configure scripts 11:43
hansg Not using %configure because the configure script is non standard and does not like being called through %configure 11:43
hansg Not using make install but DIY for various reasons 11:43
abadger1999 excluding patented code from an upstream tarball 11:44
hansg Need we go on ?  :) 11:44
spot no, i think thats enough examples. :) 11:44
spot okay, take a look at it now 11:45
spot https://fedoraproject.org/wiki/PackagingDrafts/ExplicitRequires 11:45
rdieter worksforme, +1 11:47
abadger1999 How about: :MUST: an RPM package's list of dependencies must not contain any unnecessary explicit Requires 11:47
hansg looks good, but 11:48
hansg Under "Addition to Packaging Guidelines" 11:48
abadger1999 That's just because I don't think anything else speaks to reviewers specifically. 11:48
hansg It still says: Any explicit Requires should be explained with comments in the spec file." 11:48
spot abadger1999: that is better wording. 11:48
abadger1999 Instead it's about what the package must conform to. 11:48
hansg Its a should, but still a bit strong IMHO 11:49
spot if i add "non-obvious" there... 11:49
spot would that make it less strong? 11:49
hansg Also "Packages should not contain superfluous explicit Requires within the spec file, except when absolutely necessary." is a bit double, when something is "absolutely necessary." it clearly is not "superfluous" 11:49
hansg spot, adding no obvious +1 11:50
spot hansg: how about i drop superfluous from that sentence? 11:50
hansg spot, yes that would be better 11:50
hansg +1 with those 2 changes 11:51
spot and really, we made that a must 11:51
spot so... it should be a must in the guidelines too 11:51
hansg spot, ack 11:51
spot "Packages must not contain explicit Requires within the spec file, except when absolutely necessary. " 11:51
spot okay everyone 11:52
spot one last time. 11:52
abadger1999 Okay, looks good. +1 11:52
delero +1 11:53
spot +1 from me 11:53
rdieter +1 11:53
Rathann +1 11:53
tibbs +1 11:53
racor +1 11:53
spot i'm assuming hansg's +1 holds over 11:53
hansg yes, still +1 11:54
spot it passes 11:54
spot the next item is the updated Haskell guidelines 11:54
spot https://fedoraproject.org/wiki/PackagingDrafts/Haskell 11:54
hansg Yes I was already reading them (hence the no voting) 11:54
spot I manually did a diff of the proposed new guidelines and the old ones 11:54
spot the key differences are: some of the macros have been changed (the update reflects the new ones) 11:55
spot They've improved some of the wording without changing the meaning, and they've documented the use of the "cabal" tool further 11:55
hansg +1 from me 11:56
spot +1 from me as well 11:56
Rathann I like them although I have a question 11:56
* hansg goes to help put the children in bed, back in 15 or so 11:56
Rathann why are -doc and -prof subpackages optional? 11:56
tibbs Well, the -prof packages aren't always generally useful. 11:57
tibbs -doc packages might be pointless if there's very little documentation. 11:57
Rathann all these %if %endif sections add clutter to an otherwise clean specfile 11:57
Rathann just MHO 11:58
spot yes, but that's not a new change. 11:58
Rathann +1 from me anyway 11:58
spot (and they're just templates, if you don't need those sections, you can drop them entirely) 11:58
Rathann right 11:58
tibbs +1 11:59
spot thats a +4... 11:59
racor 0, i think this all should go to rpmdev templates and not into the FPG 11:59
abadger1999 It's interesting that they have %cabal build but %cabal_install 12:00
Rathann racor: it is in rpm macros provided by the ghc package IIUC 12:00
rdieter +1 12:00
Rathann ah, you mean the spec templates 12:00
delero +1 from me 12:00
Rathann racor: yes, not a bad idea 12:00
spot okay, +6, it passes 12:01
Rathann or rpmdevtools-haskell subpackage 12:01
* spot notes that the templates aren't actually in the FPG, they're just linked to from the guidelines 12:01
abadger1999 +1 12:01
spot okay, next item (this should be fun): https://fedoraproject.org/wiki/PackagingDrafts/Absolute_symlinks_in_fonts_templates_%282009-01-02%29 12:02
spot ignore the font related text here. 12:02
spot the real question is, what do we want to require for symbolic and absolute links in Fedora packages 12:02
tibbs Did we have any luck with just doing it automatically? 12:02
spot last meeting, we hoped this could be handed with the "symlinks" utility as part of rpm 12:02
spot Jeremy looked into it, but determined that it was not possible with that tool 12:03
spot because it was finding tons of false positives due to the rpm buildroot being involved 12:03
abadger1999 enrico pointed out that relative symlinks break when bind mounting or symlinking directories. 12:03
spot The simplest solution would be to not require any sort of forced symlinking methodology and ask the rpmlint maintainer to silence that warning in Fedora 12:05
spot basically, leave how a packager creates a symlink up to the packager. 12:05
spot It seems there are notable pluses and minuses for both approaches. 12:06
Rathann indeed 12:06
Rathann I wonder why is option 3 any better 12:06
abadger1999 option 3 is what debian does but I don't think it has any advantages. 12:06
spot i think option 3 is how Debian tries to average it out. 12:06
Rathann I'd say leave it up to the packager, but maybe document pros and cons of each option 12:07
spot okay, that makes sense. what are the pros/cons of the absolute links 12:08
* spot is writing a new mini draft 12:08
tibbs The chroot issue, I guess, is the biggest one. 12:10
Rathann absolute symlinks are straightforward and easier to create (you don't get lost in multiple ../../ levels) 12:10
Rathann nicolas' draft says: "Relative symlinks may break or behave unexpectedly when a part of a filesystem is mounted to a custom location." 12:11
racor IMO, it's amd and programs which somehow try to resolve paths but get confused by obtaining unexpected results. 12:11
Rathann http://www.mail-archive.com/debian-policy@lists.debian.org/msg22444.html 12:13
racor Rathann: nicolas is right on this. It's essentially the same as what I referred to as amd issue. 12:13
racor in a nutshell it is: Which directory will tools/programs be see if /foo/boo/ is mounted under /bar/baz/ ? 12:15
Rathann something like that 12:16
Rathann also, this is a very old issue: http://www.zarb.org/pipermail/rpmlint-discuss/2006-June/000094.html 12:16
racor Rathan: This issue likely predates linux ;) 12:17
rdieter the rpmlint-discuss thread includes some additional abs->rel recipes, worth exploring? 12:18
Rathann https://www.redhat.com/archives/fedora-packaging/2006-August/thread.html#00277 12:18
spot https://fedoraproject.org/wiki/PackagingDrafts/Symlinks 12:19
Rathann in particular: https://www.redhat.com/archives/fedora-packaging/2006-August/msg00289.html 12:19
Rathann spot: s,/usr/bin,%{_bindir},g ;) 12:20
spot heh, fixed now 12:21
spot i know we're way over time, so if everyone still with us could take a look at that draft 12:22
Rathann so if this passes, what are maintainers supposed to do about bugs like this: https://bugzilla.redhat.com/show_bug.cgi?id=474057 12:22
buggbot Bug 474057: medium, low, ---, than@redhat.com, ASSIGNED, meinproc4 creates absolute instead of relative symlinks for the common directory 12:22
spot Rathann: they can decide to either make the change or close it wontfix 12:22
tibbs Does rpm have any issues with symlinks (replacing symlinks with files/directories and such) that would relate to this guideline? 12:22
spot tibbs: no, this one arose from rpmlint throwing warnings 12:22
tibbs I understand; I'm just wondering if there's any instance where rpm itself would care whether a symlink is absolute or relative. 12:23
spot not that i'm aware of. 12:24
rdieter I'm ok with the draft as-is +1, there seems to be no clear cut winner 12:25
spot I'm also +1 on this 12:25
*** rdieter is now known as rdieter_away. 12:25
--> rdieter has joined this channel (n=rdieter@pcp089243pcs.unl.edu). 12:26
abadger1999 How about: "relative symlinks will point to the same file inside or outside of a chroot" 12:26
spot as a pro? 12:26
abadger1999 As the pro. 12:27
racor spot: Can we let this proposal rest until the next meeting? 12:27
spot sure. 12:27
abadger1999 Just saying "better" leads to "Why are they better?" 12:27
spot racor: i suppose we can, if necessary 12:27
spot if possible, i'd like to vote on it now and then adjourn 12:27
abadger1999 Since there's no actions to be taken by packagers, just information I'm +1. 12:28
Rathann +1 12:28
racor abadger1999: rel symlinks are better in most cases ;) 12:28
spot I count +4 for this 12:28
abadger1999 heh 12:28
racor spot: My time's up, I got to go, bye. 12:28
spot racor: thanks for your time 12:28
spot tibbs, delero, hansg? 12:28
hansg I'm back, what should I vote about ? :) 12:29
spot https://fedoraproject.org/wiki/PackagingDrafts/Symlinks 12:29
tibbs I'm sort of ambivalent. 12:29
spot tibbs: then this is the perfect draft for you, as it really lets the packager decide. ;) 12:30
hansg +1 from me 12:30
spot okay, thats +5, but if anyone else wants to vote on the record, feel free 12:30
nim-nim relative symlinks have one more cons 12:31
nim-nim they assume the value of rpm directory macros is known beforehand and set in stone 12:31
Rathann I wonder how relative symlinks are better, aside from the chroot issue 12:31
tibbs How about some requirement that packagers be consistent? 12:31
tibbs Or is that important? 12:31
spot tibbs: I think there is merit in that 12:32
spot is anyone opposed to adding a line that says that packagers should be consistent with the symlinking method throughout a package? 12:32
nim-nim spot: what's the value? 12:33
nim-nim sometimes making a relative symlink will be trivial 12:33
delero not a big fan of absolute symlinking 12:33
spot well, if half of a package works with a chroot and the other half doesn't... 12:33
spot i think it would be better if all of it worked or none of it. 12:33
spot less unexpected surprises. 12:33
spot "Packagers should use their best judgement when deciding which method of symlink creation is appropriate, but should also be consistent with whichever method they choose." 12:34
Rathann spot: +1, even if that's obvious 12:34
nim-nim spot: the case is when your package creates its own directory tree and does relative symlinks within it 12:34
nim-nim (which is what the debian people tried to express IMHO) 12:34
nim-nim but anyway I don't care as long as the warning is shot 12:35
spot ehh, okay, i see that point. 12:35
spot i"Packagers should use their best judgement when deciding which method of symlink creation is appropriate, but should also be consistent with whichever method they choose to use in the spec file." 12:35
spot how about that? 12:35
spot or should we just drop the consistency... 12:35
spot eh. i'll drop the consistency req. if we really need it, we can add it later. 12:36
nim-nim spot: IMHO the "consistency" thing is just too hard to define in a sane way 12:36
spot nim-nim: yeah, i think you're right 12:36
spot okay, the floor is open to any other items 12:36
spot please keep in mind, we're waaay over time for today. :) 12:36
abadger1999 spot: Well... /usr/bin/gzcat => gzip could be a valid relative symlink amidst more major absolute symlinks 12:36
Rathann abadger1999: it's in the same directory, those are quite safe 12:37
abadger1999 (sorry... was aimed at droppin gconsistency) 12:37
spot if there are no other new issues, i'm going to call the meeting... 12:37
nim-nim spot: just a question, what is the procedure to add a "check your font files" to the package review list? 12:38
Rathann abadger1999: ah, right :) 12:38
spot nim-nim: just write a draft that has the line you want to add to the ReviewGuidelines 12:38
* nim-nim does not want to do another audit next year 12:38
nim-nim spot: ok, will do 12:38
spot alright, we're done for today. 12:39
spot thanks everyone. 12:39
Retrieved from "https://fedoraproject.org/w/index.php?title=Packaging:Minutes/20090120&oldid=72453"