Fedora Packaging Committee Meeting of 2007.04.17
- AxelThimm (
- JasonTibbitts (
- JesseKeating (
- RalfCorsepius (
- RexDieter (
- TomCallaway (
- ToshioKuratomi (
- VilleSkyttÃ¤ (
The following drafts have been accepted by FESCo and are to be written into the guidelines:
- A statement of the responsibilities of reviewers and packagers during the package review process PackagingDrafts/OverallReviewGoals
- Guidelines for conflicting packages and the use of Conflicts: PackagingDrafts/Conflicts
One item was discussed on the fedora-packaging mailing list:
- Minor clarifications to the filename encoding guidelines: https://www.redhat.com/archives/fedora-packaging/2007-April/msg00156.html
- Accepted on-list (5 - 0)
- Voting for: abadger1999, f13, spot, thimm, scop
- Voting against: (none)
- Since these were on-list, please see the above-linked thread for the votes themselves.
The following additional items were discussed; see the logs for full details.
- The guidelines contained a few references to fedora-extras-list; these have been altered to point to fedora-devel-list instead.
- The Committee waded with much trepidation into the issue of guidelines for the creation of users and groups. This is a complex issue which I won't attempt to summarize, but it will require significantly more discussion.
- Meeting time: We'll have to block out time in a wiki table and try to narrow something down. At the moment it looks like 1600UTC satisfies the most people, except for cutting into f13's lunchtime.
[12:03] * tibbs is here. [12:03] * scop here [12:04] * rdieter goes to grab something snacky... [12:04] <racor> I am here, but have ca. 10mins left before having to go [12:05] <tibbs> Yes, we really need to decide what to do about the meeting time. [12:05] <tibbs> But at this point it doesn't look like we have a chance of starting on time. [12:08] * abadger1999 is here [12:08] <tibbs> Well, that would be five if rdieter gets back before racor has to leave.... [12:08] <rdieter> here [12:09] <tibbs> Well, there's http://fedoraproject.org/wiki/PackagingDrafts/FixMailingListRefs [12:09] <tibbs> Basically, we reference extras-list in some guidelines. What list should we reference instead? [12:09] <tibbs> fedora-devel or fedora-maintainers? [12:10] <tibbs> And do we even need to bother with voting for this and ratifying it? It seems pretty trivial and necessary since extras-list is gone. [12:10] <rdieter> "just do it" [12:11] <rdieter> I'd lean toward migrating most items to fedora-maintainers [12:11] <abadger1999> spot, lutter, thimm: Roll call (Packaging meeting) [12:11] <tibbs> I'm concerned that -maintainers has the perception of being only for existing maintainers, while the guidelines are for new packagers as well. [12:11] <abadger1999> rdieter: Except new packagers don't have access. [12:12] <racor> rdieter: maintainers won't work for "New maintainers" because maintainers is a closed list [12:12] <tibbs> So -devel? [12:12] * spot is here [12:12] <racor> why not packaging@ ? [12:12] <abadger1999> f13: (packaging meeting) [12:12] <rdieter> oh, closed = no outside posters? ok -> fedora-devel then. [12:12] <spot> i think -devel [12:13] <tibbs> So, just do it, or go through ratification? [12:13] <abadger1999> I could see the first three going to packaging. [12:13] <rdieter> fedora-packaging may be good for some inquries (packaging-specific questions, guideline clarifications, for example). [12:13] <abadger1999> Kmods definitely go to -devel [12:13] <spot> kmods go to -devel [12:13] <tibbs> I don't know if we should modify the policy document or if FESCo should. [12:14] <spot> tibbs: lets let FESCo do that [12:14] <tibbs> And whoever was driving that draft should fix it up. (scop was the last one in there). [12:14] <rdieter> technically, FESCo should, but imo, doesn't matter as long as it gets done. [12:14] <spot> if they bounce it back to us for whatever reason, then we'll deal with it [12:14] <tibbs> I'll just bring it up on Thursday and make the change then. [12:15] <tibbs> So I'll just change the first three refs to fedora-devel now? [12:15] <rdieter> yeah [12:15] <scop> tibbs, which draft are you referring to? [12:15] <tibbs> http://fedoraproject.org/wiki/PackagingDrafts/KernelModulesWithKverInName [12:16] <scop> hmm [12:16] <scop> we have http://fedoraproject.org/wiki/Packaging/KernelModules [12:16] <tibbs> I just did a search and picked out documents we may need to deal with. [12:17] <spot> i think that draft may be abandoned at this point [12:17] <scop> the draft should probably be just deleted and redirected to Packaging/KernelModules [12:17] <scop> I'll have a look [12:18] <thl> the current plan in my head and discussed at fudcon is to revisit kmod packaging for f8 [12:18] <thl> that includes kverinname [12:18] <thl> which is likely afaics [12:18] <tibbs> I'm changing Guidelines and NamingGuidelines now. [12:18] <f13> so I should really learn how to tell time. [12:18] <scop> thl, orthogonal issue, we really don't want to go there right now :) [12:18] <spot> ok, so, lutter isn't here... no ruby update [12:19] <thl> scop, sure, that was just meant as FYI ;-) [12:19] <jwb> f13, i have the same problem [12:19] <spot> scop: anything on user/groups? [12:19] <scop> a bit, but the draft will need some more work [12:19] <spot> ok. let us know when you're ready. [12:19] <scop> well, I think we could discuss it already for a bit [12:20] <scop> Requires(pre): /usr/sbin/groupadd [12:20] <scop> Requires(pre): /usr/sbin/useradd [12:20] <scop> %pre [12:20] <scop> # Add -g GID where appropriate [12:20] <scop> /usr/sbin/groupadd -r -f GROUPNAME [12:20] <scop> # Add -n and/or -u UID where appropriate [12:20] <scop> id USERNAME || \ [12:20] <scop> /usr/sbin/useradd -c COMMENT -d HOMEDIR -g GROUPNAME -r USERNAME [12:20] <scop> I think that pretty much covers the basics [12:21] <scop> noteworthy things: [12:21] <scop> users/groups not deleted [12:21] <spot> ok... so basically, if the username isn't on the system, add one with the next available UID [12:21] <scop> s/username/groupname/ [12:22] <scop> or? [12:22] <spot> no, i'm looking at the id || useradd line [12:22] <scop> use next available or static mapping is a matter of whether -u UID is used [12:23] * spot nods [12:23] <spot> is this going to plugin to a table of UID maps in the wiki? [12:23] <notting> please? static? [12:23] <spot> my concern is this [12:23] <spot> someone registers UID 20 [12:23] <spot> i don't have the app installed that is static at 20 [12:23] <spot> i install something that is dynamic, it takes 20 [12:24] <spot> then, i install the static app [12:24] <spot> boooooom [12:24] <scop> nope, see -f to useradd [12:24] <rdieter> dynamic will(should) never get uid 20 [12:24] <scop> eh, groupadd [12:24] <spot> rdieter: i chose 20 to keep the numbers low, not because it was valid. :) [12:25] <racor> sorry, I've got to go, bye. [12:25] <scop> another noteworthy thing about the above is that there's no "|| :" safeguards in either useradd or groupadd [12:25] <spot> racor: thanks. [12:25] <spot> I think we should mandate static mapping [12:25] <scop> ie. the install/upgrade *will* fail if the user/group addition breaks [12:25] <scop> I think we should forbid static mapping :) [12:25] <spot> if your app needs a UID, then it needs to register in a table and use a static UID [12:25] <rdieter> spot: +1 [12:26] <spot> well, we either need to force it or forbid it [12:26] <thimm> why? [12:26] <spot> i think by forcing it we can ask hard questions "do you really need this? do you know what you're doing?" [12:26] <thimm> LSB allows both [12:26] <rdieter> what about the concern of running out of static-space? [12:26] <scop> seriously, you don't see any middle ground there? [12:26] <thimm> and even mandates slots [12:26] <spot> scop: if you mix you get the conflict above [12:27] <spot> foo sets static UID 550, bar gets installed first, grabs unused UID 550 [12:27] <thimm> static and dynaminc stlots don't overlap [12:27] <spot> foo tries to install, can't get static UID 550 [12:27] <spot> thimm: not even if someone says -u for a UID in the dynamic range? [12:28] <thimm> The LSB says [12:28] <thimm> 0-100: static [12:28] <thimm> 101-499: dynmaic [12:28] <spot> thimm: we're using a lot of the static UIDs already [12:28] <spot> it is forseeable that we will exhaust 0-100 [12:29] <rdieter> ins't that why /etc/login.defs includes: UID_MIN 500 (and GID_MIN 500) (by default)? [12:29] <thimm> Slight correction: [12:29] <thimm> 0-99 static, 100-499 dynamic [12:29] <thimm> http://refspecs.freestandards.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/uidrange.html [12:29] <notting> "dynamic allocation by system administrators and post install scripts using useradd." [12:30] <spot> notting: thats 100-499 ? [12:30] <notting> yes. now to argue whether dynamic modifes 'by system administrators only', or both ;) [12:31] <rdieter> both, clearly. :) [12:32] <tibbs> I think it's far easier to patch kickstart to add a simple user creation facility before the packages are installed than to actually come to the end of this discussion. [12:32] <scop> tibbs++ [12:32] <spot> kickstart? or yum. [12:32] <rdieter> tibbs: so no new system UID/users after install? [12:32] <spot> it seems yum is the better place for this [12:33] <scop> yum? you mean rpm? [12:33] <spot> well, either. [12:33] <tibbs> The problem with using dynamic UIDs is that some admins want them to be consistent across multiple installations. [12:33] <spot> yum could look for userid groupid defines in packages, queue em up, and make em. [12:33] <scop> I think implementing that in yum is wrong [12:34] <tibbs> So you just add the UIDs before installing the packages and all is well, but you can't do that if you kickstart your machines. [12:34] <spot> yes, but if we do it in rpm i'll end up having to talk to jbj. [12:34] <tibbs> Hence, quick fix in kickstart. [12:34] <rdieter> am I missing something, can't we statically assign what's used in the 101-499 range too? (or not)? [12:34] <spot> tibbs: doesn't handle post-install user/group creation as well [12:34] <tibbs> Not sure you mean. It handles useradd in %post just fine. [12:34] <notting> rdieter: that would be my suggestion [12:34] <thimm> What exactly are we trying to fix? [12:35] <thimm> Are we sure whatevr we try to fix is really brokne? [12:35] <rdieter> notting: then, that makes the most sense to me. [12:35] <spot> thimm: i think we're trying to document how to add users/groups in rpm packages [12:35] <tibbs> I'm just trying to cover the single case that I laid out two minutes ago. [12:35] <tibbs> Which seems to be the only real issue that I've seen. [12:35] <thimm> spot: And why is suddenly yum and kickstart part of it? [12:35] <scop> kickstart is the *essence* of it [12:36] <scop> that's what people are complaining about [12:36] <abadger1999> rdieter: Doesn't that run into the collision problem? [12:36] <thimm> ??? [12:36] <tibbs> If you kickstart a machine, you have no way to fix the UIDs that a dynamic assignment will use. [12:36] <abadger1999> ie: sys admin allocate 101 to foo [12:36] <thimm> That's why they are dynamic, right? [12:36] * spot is rather confused now [12:36] <abadger1999> bar installs and requests a static 101 for baruser? [12:36] <rdieter> abadger1999: slap said sysadmin, move on. [12:36] <tibbs> They're dynamic from the standpoint of the distro. [12:36] <spot> any chance of someone who understands this actually writing a draft? [12:36] <rdieter> :) [12:37] <abadger1999> rdieter: it's legal if the range is being used for dynamic assignments. [12:37] <tibbs> There are valid curcumstances where they can't be dynamic from the standpoint of an individual installation. [12:37] <thimm> There is lots of noise that we need static uids, I don't think we do [12:37] <scop> we as a distro don't, but local policies may be different [12:37] <tibbs> The distro doesn't; individual admins may (and indeed many do, hence the entire discussion). [12:37] <rdieter> thimm: consistent UID's for same users across multiple boxes. [12:37] <thimm> FWIW kickstart has a %rpe section, stuff any "loca-static" uids there. [12:38] <tibbs> There's no password file to add them to in %pre. [12:38] <tibbs> In fact, they can't be added until after some packages have been installed, hence the pain. [12:38] <spot> tibbs: ok, so this sounds like an RFE against anaconda. [12:39] <thimm> Well, then maybe make a kind request to Jeremy and firends to allow for passwd.addon? [12:39] <rdieter> the only approaches that seem to address consistent assignment of dynamic space is: strict/assigned static allocation, fedora-usermngt [12:39] <rdieter> and we all know how loved the latter is. [12:39] <thimm> fedora-usermngt is not doing static allocation [12:39] <scop> of course, sysadmins could just grab the "setup" package, add the UIDs they need, bump EVR and rebuild, and use that instead of the vanilla distro one [12:40] <thimm> scop++ [12:40] <thimm> Very nice idea [12:40] <rdieter> thimm: I never said it did, I said it tackled "consistent assignment". [12:40] <thimm> rdieter: The only thing that has save fedora-usermngt to date is that by default it is dormant [12:41] <scop> with regards to the draft, I'm still on it [12:41] <tibbs> I really dislike having to rebuild pieces of the distro to get basic functionality, though. (Queue grumbling about default yum repos.) [12:41] <rdieter> thimm: please stay on topic, I have no wish to discuss the merits or demerits of fedora-usermngt. I was only making a point that I see only 2 alternatives. [12:41] <tibbs> But I guess now that we can specify multiple repos in kickstart, this isn't such a big deal. [12:41] <thimm> Anyway, preloading passwd/group at anconda time is probably nothing we would ever make a guidline out, right? [12:41] <spot> thimm: its not a packaging issue. [12:42] <rdieter> anaconda, imo, is not the end-all-be-all solution here. [12:42] <thimm> rdieter: The issues seems to be that admins have not way to inject their favourite uid/giod tables [12:42] <rdieter> packages/systems should be able to create system users/accounts post-install (imo) [12:43] <spot> rdieter: i agree. and I'd like to see a draft describing how this should be done. [12:43] <thimm> That's not possible [12:43] <scop> post-install? [12:43] <rdieter> thimm: that's even a smaller audience than the "I want consistent uids" group, imo. :( [12:43] <thimm> How will rpm's uid/gid be used postinstall? [12:43] <spot> scop: or rather, after anaconda is done. [12:43] <rdieter> post-install (post-anaconda) [12:44] <scop> ok, was thinking about %post in packages [12:44] <tibbs> Well, I'm prepared to accept "rebuild setup if you want to fix UIDs at kickstart time, otherwise add the UIDs before you install the packages" and dump fedora-usermgmt. [12:44] <spot> packages should be able to create system users/groups when they are installed in a predictable, safe, documented way. [12:44] <spot> Now. someone write a draft that tells me how and why. ;) [12:44] <rdieter> spot: +1 [12:44] <thimm> spot, rdieter: packages need to create their user in their %pre, nothing else seems to make sense [12:45] <spot> thimm: no one is saying they shouldn't. [12:45] <rdieter> well, duh. :) [12:45] * f13 ignores rdieter's typo (: [12:45] <thimm> Well, "after anaconda is done" sound not like the packages' %pre part ;) [12:45] * spot sighs [12:46] <spot> the bike shed is not yellow! [12:46] <spot> ok. now, scop, let us know when you've got a draft to review? :) [12:46] <tibbs> A utility to change the UID that a package is using shouldn't be all that touch to cook up. [12:47] <scop> I can write one, but I'd rather not write three [12:47] <spot> scop: then write one [12:47] <notting> tibbs: find / is unpleasant, though [12:47] <scop> (1: static mandatory, 2: static forbidden, 3: mix of 1 and 2) [12:47] <tibbs> Indeed it is, but it should still be possible. [12:47] <spot> scop: its your draft, write what you think is the best. [12:48] <scop> okay, will do [12:48] <spot> ok. are there any other issues people want to discuss? [12:49] <abadger1999> I just want to say The UTF wording changes were approved on list. [12:49] <spot> ok. [12:49] <-- notting has left this server ("Ex-Chat"). [12:49] <rdieter> thank all that is holy. [12:49] <abadger1999> So that gets mentioned in the writeup. [12:49] <spot> tibbs: did everything pass FESCO ratification? [12:49] <tibbs> We didn't present any drafts last week. [12:49] <rdieter> so, yes? :) [12:49] <spot> Conflicts/Responsibilities ? [12:50] <tibbs> You're right, I'm confused. [12:50] <tibbs> Yes, those passed. [12:50] <spot> ok. i'll mark them as writeup [12:50] <spot> i'm also going to make a new wiki table for "meeting times that work for me on Tuesday" [12:51] <tibbs> That meeting got messy as the wiki croaked in the middle. [12:51] <spot> we'll see if we can find a new meeting time that includes everyone [12:51] <rdieter> ah, good times. [12:51] <tibbs> And I just found out that it ate last week's minutes. But mmcgrath resurrected them. [12:51] <spot> ill send an email to the mailing list when it is ready for everyone to fill in their "good times" [12:52] <f13> spot: does it have to be Thursday? (: [12:52] <spot> f13: you mean tuesday? [12:52] <f13> because really, meeting day of doom. [12:52] <f13> holy crap something is _not_ right with me. [12:52] <spot> f13: i've known that for years. ;) [12:53] <spot> f13: sure, what the hell, why not open it up. [12:53] <spot> i'll put the whole week in there, people can play fill in the blank [12:53] <f13> fun [12:53] <f13> Can I win a bingo? [12:53] <tibbs> I have no particular weekday preference, but Wednesday and Thursday are probably bad choices if you want to get things through FESCo quickly. [12:54] <spot> tibbs: thats a good point [12:54] <spot> so, monday, tuesday, or friday [12:54] <tibbs> Finally found the FESCo log: [12:54] <tibbs> [Thu Apr 12 2007] [12:41:02] <bpepple> tibbs: I consider these guidelines approved by FESCo. [12:55] <thimm> Empty and reuse http://fedoraproject.org/wiki/Packaging/NewMeetingTime? [12:55] <spot> thimm: yep. probably. [12:55] <thimm> OK, anything else, or are we splitting? [12:55] <spot> i hope not. i'm hungry. [12:55] <spot> :) [12:56] <thimm> I'll need to afk for a couple of minutes, if that's all, bye all! [12:56] <spot> ok, thats it. thanks everyone. [12:56] <abadger1999> thanks spot [12:57] <scop> thanks