From Fedora Project Wiki

The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

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"