Packaging:Minutes20070417

Present

 * AxelThimm
 * JasonTibbitts
 * JesseKeating
 * RalfCorsepius
 * RexDieter
 * TomCallaway
 * ToshioKuratomi
 * VilleSkyttÃ¤

Writeups
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

Votes
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.

Other Discussions
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.

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