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:

Votes

One item was discussed on the fedora-packaging mailing list:

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
Retrieved from "https://fedoraproject.org/w/index.php?title=Packaging:Minutes20070417&oldid=66535"