From Fedora Project Wiki

Fedora Packaging Committee Meeting 2009-01-06

Present

  • Denis Leroy (delero)
  • Jason Tibbitts (tibbs)
  • Rex Dieter (rdieter)
  • Tom Callaway (spot)
  • Toshio Kuratomi (abadger1999)

Regrets

  • Dominik Mierzejewski (Rathann|work)
  • Hans de Goede (hansg)
  • Ralf Corsepius (racor)
  • Xavier Lamien (SmootherFrOgZ)

Writeups

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

Votes

One proposal is submitted to FESCo this week:

Other Discussions

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

IRC Logs

* spot is here 11:00
spot ping: abadger1999, rdieter, SmootherFrOgZ, ubertibbs 11:02
ubertibbs Yep. 11:02
rdieter yo 11:02
abadger1999 present 11:02
spot hans emailed me to let me know he would be absent 11:03
abadger1999 so not a lot of people.... 11:04
--> delero has joined this channel (n=denis@nat/sun/x-c6cd67f1f741f42b). 11:04
ubertibbs It's still Christmas, after all. 11:04
spot with delero, that's five. 11:05
* delero is still alive 11:05
spot :) 11:05
spot so, lets get to the fun stuff 11:05
spot https://fedoraproject.org/wiki/PackagingDrafts/Font_package_splitting_rules_%282008-12-21%29 11:05
ubertibbs The "Current wording" is a whole lot bigger than the "New wording", isn't it? 11:07
spot yes. 11:07
spot well, no. 11:07
ubertibbs I think "one paragraph" is intended to say "one section". 11:08
spot yeah, thats what he meant 11:08
ubertibbs I was trying to figure out where the changed paragraph was. 11:08
rdieter the revised clarity is nice, I think I like it. 11:08
spot rdieter: yeah, i agree. 11:09
spot any other comments, or should we vote on this? 11:10
ubertibbs Seems OK to me. +1 11:11
spot +1 from me 11:11
delero the vote is only on the rewording ? 11:11
abadger1999 +1 11:11
ubertibbs I'm dismayed that this level of bureaucracy is needed, but if it is needed then at least it should be clear. 11:11
spot delero: yes, the vote is to use the new wording 11:11
abadger1999 It looks like clarification rather than actual changes. 11:11
spot abadger1999: mostly, yes. 11:11
rdieter +1 11:12
* spot waits for delero's vote 11:13
delero +1 for the rewording 11:13
spot great (one sec) 11:14
spot okay, next item: https://fedoraproject.org/wiki/PackagingDrafts/Font_package_naming_%282008-12-22%29 11:16
ubertibbs I've always wondered why the "fonts" bit in the name didn't come first. 11:17
* spot shrugs innocently 11:17
spot i'm not going to spend a lot of time arguing about paint colors with the people who are doing the painting 11:18
spot this naming schema is generally consistent 11:18
ubertibbs But if someone's talking about renaming everything, might as well have it make the maximal amount of sense so it doesn't have to happen again. 11:18
spot thats true 11:18
ubertibbs I don't disagree that it's consistent; I just wish the question had been addressed. 11:19
delero ubertibbs: this to be consistent with font subpackages (foo and foo-fonts)... 11:20
ubertibbs I don't quite understand that. 11:20
spot i don't think thats really an argument, the subpackage could easily be fonts-foo 11:21
ubertibbs fonts-foo is also consistent with that. 11:21
delero right, but I'd hate that personally 11:21
delero having the foo src.rpm generate "foo", "foo-devel", "foo-libs" and "fonts-foo"... 11:21
ubertibbs I suppose I should have asked this previously so it wouldn't hold up a vote. 11:22
spot from a logical sorting perspective, having "fonts-foo" is saner imho 11:22
spot but i really am indifferent, i wouldn't vote against it over that 11:22
ubertibbs In any case, we're far from consistent on this across the distro. 11:22
spot yes, and this is part of an effort in the F11 timeframe to become consistent 11:22
abadger1999 I like the goal but I think I need to understand a bit more about this... 11:23
abadger1999 Which is more generic a foundry or a fontproject? 11:23
ubertibbs Well, it makes all of the font names consistent. I was referring to the fact that some things are prefixed and others are postfixed across the distro. 11:23
rdieter ubertibbs: examples? 11:24
abadger1999 "fonts" is the largest category and "fontfamilyname" is the smallest but they're right next to each other. 11:24
ubertibbs I mean, we could mandate devel-foo and then all of the devel packages would sort together. But we don't. 11:24
abadger1999 python-MODULENAME vs FOUNDRY-PROJECT-fonts 11:25
ubertibbs And blah-perl versus perl-plugh examples are rampant. 11:25
rdieter I understand the temptation, but that comparison is kinda apples vs. oragnes 11:25
rdieter oranges even 11:25
abadger1999 also, -fonts is not a consistent suffix in these guidelines... sometimes the font-family subpackage portion of the name comes afterwards. 11:26
ubertibbs That does make it somewhat confusing. 11:26
spot abadger1999: thats a good point. 11:27
ubertibbs Given this guideline, how do I ask yum for a list of fonts? 11:27
spot i think we need to bounce this back to nim-nim to A) consider using "fonts-" as a prefix (or at least justify why not) and B) ensure consistency with the naming schema 11:27
ubertibbs I guess '*fonts*' is the best option, but... 11:27
delero yum search fonts ? 11:27
ubertibbs Yeah, yum search fonts would find fontforge, wouldn't it? 11:28
ubertibbs I get the sense that for whatever reason, people have an issue with using %package -n in a specfile. 11:30
spot okay, since there seems to be no opposition, i'll table this and send email to nim-nim 11:30
spot next item: https://fedoraproject.org/wiki/PackagingDrafts/Absolute_symlinks_in_fonts_templates_%282009-01-02%29 11:30
spot Ignore the font portion of this draft, what he really wants us to do is come up with a policy on symlink usage in Fedora packages 11:31
abadger1999 spot: I'd also like to see the name go from most general->most specific.... which should just be moving fonts as a prefix. 11:31
spot rpmlint complains if a symlink is not relative 11:31
ubertibbs I personally think that all symlinks should be relative. 11:31
spot He also notes that Debian's policy is "in the same top dir, relative. if not, explicit." 11:32
spot i personally think there is value in requiring relative symlinks across the board 11:33
spot even if it makes things a little trickier with macros and whatnot 11:33
ubertibbs I admit to not understanding how "in the same top dir" makes any difference. If they're in the same directory, the link has no pathname component at all, so surely that's not what they're talking about. 11:34
spot ubertibbs: if i am in /foo and i link to bar, it is relative 11:34
spot if i am in /foo and i link to /foo/bar, it is not 11:34
ubertibbs Yes, I fully understand that. But what would be an example under the debian policy of an acceptable absolute link? 11:35
spot if i am in /etc and i link to /foo/bar 11:35
ubertibbs I fail to see the value of that exception, then. 11:35
spot the logic there (as best i understand it) is this 11:36
spot if you're going backwards and trying to leverage macros 11:36
spot if those macros change in number of directories in a path 11:36
spot the symlink will break 11:36
ubertibbs I wonder, what prevents rpmbuild from simply converting the symlinks to relative ones at build time? 11:37
spot hypothetically, a macro path could have a different number of directories, depending on arch. 11:37
delero but if a macro path changes, absolute symlinks will also fail... 11:37
rdieter I'm tempted to go with "Option 1: Do not care", what's the real-world breakage/problem/justification here? 11:37
ubertibbs chroots. 11:37
spot delero: not on a rebuild, they wouldn't. 11:37
spot whereas, they would with a relative symlink 11:37
rdieter I must be dumb, but I faild to see how chroots would be adversely affected either way 11:37
delero but u need a rebuild in both scenarios... 11:38
ubertibbs Absolute links point to different files when you're inside the chroot. 11:38
spot delero: yes, but the symlink operation will be incorrect when the macro changes 11:38
rdieter you mean operating on a chroot, but outside of it? 11:38
abadger1999 Looking at a chroot when not in the chroot environment. 11:38
ubertibbs relative symlinks are consistent both in and out. 11:38
abadger1999 yeah 11:38
spot if %{mymacro} is set to /usr/lib/spot 11:38
rdieter that's just asking for fail anyway, isn't it? 11:38
spot and i use it in a symlink with backwards steps 11:38
spot ln -s ../../../%{mymacro} 11:39
rdieter or is that the mock/buildsys case? 11:39
spot also, relative symlinks can be much uglier. 11:40
spot it is easier to link foo to /usr/bin/foo when it lives in /usr/share/oh/god/will/the/java/pain/ever/stop 11:40
spot (in an explicit way) 11:40
spot but as i said, i think there is still value in mandating relative symlinks across the board (option 2 in the draft) 11:41
* spot wonders if everyone put him on ignore. ;) 11:43
rdieter ok, but is the pain of requiring knowledge of the macro, to know how many ../ 's to prepend worth it? 11:43
spot rdieter: debian didn't think so. 11:43
* delero is not ignoring spot :-) 11:43
abadger1999 If we use the symlinks command then I think the pain mostly goes away. 11:44
delero i have a preference for option 2 11:44
spot abadger1999: i'm not sure how the symlinks command replaces ln 11:44
abadger1999 From the man page, I don't think it does. 11:44
abadger1999 Instead it is run afterwards. 11:44
jeremy correct 11:45
spot ahh, okay 11:45
ubertibbs Yes, you just run it and it relativizes all of your links. 11:45
abadger1999 Which makes ubertibbs point about having rpmbuild do it very relevant. 11:45
spot it seems like rpm should be doing that for us if we want it 11:45
ubertibbs The macro issue is really a non-issue, because you just fix up your links later. 11:45
spot ubertibbs: indeed 11:45
ubertibbs But it would be kind of neat to get rpmbuild to do this and not have to bother with it anywhere. 11:46
ubertibbs Sort of like compressing manpages. 11:46
jeremy it could at least be done as part of %__spec_install_post easily 11:46
ubertibbs Can we punt until we investigate that? 11:47
rdieter punt +1 :) 11:47
ubertibbs Who would be the person to talk to? 11:48
spot panu, i will send email to rpm-maint 11:48
jeremy panu if in rpm itself, could easily be done in redhat-rpm-config as well in which case... uhhh, me maybe? 11:48
spot jeremy: which would you prefer? 11:49
jeremy it's really six of one, half dozen of the other. we tend to put packaging policy in redhat-rpm-config, so it likely makes more sense there 11:49
spot okay, please make that change in rawhide then. 11:50
spot thats all the issues i had for today 11:50
ubertibbs Well, make sure it works, I guess. 11:50
jeremy ubertibbs: indeed :-) 11:50
spot ubertibbs: yeah, thats really what i meant. :) 11:51
ubertibbs At some point we'll have to address the ongoing calls to move the guidelines out of the wiki. 11:51
spot ubertibbs: i think those have been addressed for the time being 11:51
jeremy do we have any packages which are using an absolute symlink right now that have a reason for doing so? 11:51
ubertibbs I thought our need for ACLs were preventing a mediawiki upgrade. 11:51
abadger1999 ubertibbs: I have joined the fedora-docs list and started talking to them. 11:51
spot ubertibbs: no, they did some moving about and now we're in a namespace (Packaging:Foo) 11:51
rdieter good to know 11:52
ubertibbs Heh, I didn't even notice. 11:52
abadger1999 ^ That allows us to use a different acl plugin that's compatible with the new MediaWiki. 11:52
ubertibbs Does that give us anything else, like the kind of notifications we were looking for? 11:52
spot ubertibbs: i don't know, i will ask 11:52
ubertibbs Also, there's the issue of PackagingDrafts. I'm concerned that it needs a cleanup. 11:53
spot probably. 11:53
ubertibbs I often see people referring to documents there, and I wonder if that will eventually prove problematic. 11:53
spot i also need to finish the cleanup of the reviewguidelines 11:54
ubertibbs I'm not even sure how to find the list of pages under PackagingDrafts. The wiki and I rarely get along. 11:54
nirik just if you all have time/want to, any comments on: https://fedoraproject.org/wiki/PackagingDrafts/RenamingPackages (I meant to try and submit it to the schedule, but I didn't) ? 11:55
spot nirik: i almost think FESCo needs to decide that 11:56
ubertibbs Yes, this really is a policy issue. 11:56
nirik ok, it is more package lifecycle/policy than guideline for packaging. 11:56
ubertibbs As long as our guidelines for Provides and Obsoletes are sane, this isn't really our gig. 11:57
spot okay, anything else? going once, going twice? 11:57
*** spot sets the channel topic to "Channel is used by various Fedora groups and committees for their regular meetings | Note that meetings often get logged | For questions about using Fedora please ask in #fedora | See http://fedoraproject.org/wiki/Fedora_meeting_channel for meeting schedule". 11:58
spot alright. thanks everyone. 11:58
Retrieved from "https://fedoraproject.org/w/index.php?title=Packaging:Minutes/20090106&oldid=68693"