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:
- RubyGem with C code - PackagingDrafts/RubyGem_with_C_code
- Font packaging automation - PackagingDrafts/Fonts_packaging_automation
- Updates to the Eclipse plugin guidelines
- Make adherence to the FHS a MUST, with the added exception of /usr/<target> for cross toolchains.
Votes
One proposal is submitted to FESCo this week:
- Font package splitting rules
Other Discussions
The following additional items were discussed; see the logs for full details.
- Font package naming - http://fedoraproject.org/wiki/PackagingDrafts/Font_package_naming_%282008-12-22%29
- Passed back to the submitter with comments and questions.
- Use of absolute symlinks in packages - http://fedoraproject.org/wiki/PackagingDrafts/Absolute_symlinks_in_fonts_templates_%282009-01-02%29
- Turns out that rpm can be made to convert all symlinks to relative ones transparently, so that's being experimented with first.
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 |