From Fedora Project Wiki
Fedora Packaging Committee Meeting of 2007.04.17
Present
- AxelThimm (
thimm) - JasonTibbitts (
tibbs) - JesseKeating (
f13) - RalfCorsepius (
racor) - RexDieter (
rdieter) - TomCallaway (
spot) - ToshioKuratomi (
abadger1999) - VilleSkyttä (
scop)
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] <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