Packaging:Minutes20070508

Present

 * AxelThimm
 * JasonTibbitts
 * RalfCorsepius
 * ToshioKuratomi
 * VilleSkyttä

Note: Many members were en route to or at the Red Hat Summit and so there were insufficient members for a quorum.

Writeups
The following drafts have been accepted by FESCO and are to be written into the guidelines:


 * Two PHP proposals: http://fedoraproject.org/wiki/PackagingDrafts/PHP (the first two items only: PECL Extensions and Versioned BuildRequires in Macros Section)
 * Ruby Gems guidelines: http://fedoraproject.org/wiki/PackagingDrafts/RubyGems

Votes
There were no votes made as a quorum was not present.

Other Discussions
The following additional items were discussed; see the logs for full details.


 * Some progress on http://fedoraproject.org/wiki/PackagingDrafts/UsersAndGroups; we will probably vote on this next week.

IRC Logs
[12:00] * tibbs|h here [12:00] *** You are now known as tibbs. [12:00] * tibbs here too [12:03] * scop here [12:03] * thimm her [12:04] * abadger1999 here [12:04] half here [12:07] Doesn't look good. [12:07] Is this summit week? [12:08] I think so. [12:09] Did everyone at least block out the times that are good or bad for them on the wiki page? [12:09] Well, we're 5 people, do we want to continue the meeting? [12:09] <-- lutter has left this server ("Leaving."). [12:09] Well, it was almost six there. [12:12] * abadger1999 fills in his times. Same as the last time we did this. [12:12] Does anyone want to report on progress on any item om GuidelinesTodo? [12:13] It's too bad we won't be able to look at the emacs guidelines, but perhaps they need to stew for a bit longer anyway. [12:13] If anyone has ratify items, they're all writeups now as FESCo had no complaints. [12:14] I find it strange that nobody has commented on PackagingDrafts/UsersAndGroups in two weeks [12:14] I think we should make a phony decision to test whether anyone notices with the current scheme [12:14] "All specfiles need to be written in big 5" ... [12:14] Well, I reported it to FESCo and asked for input. [12:14] scop: I thought you wanted to finish it up, it looked very good up to what was posted. [12:15] The problem is that the complainers won't come out of the woodwork until we've already voted. [12:15] They they'll say that we're railroading the draft through. [12:15] What's "railroading"? [12:16] Forcing something through ignoring opposition. [12:16] well, http://www.redhat.com/archives/fedora-packaging/2007-April/msg00199.html [12:16] A train is rather hard to stop, after all. [12:17] I think I'll reply to that one saying that since there were no comments, we're preparing to ratify the current draft [12:17] scop: At first I thought that should cover everything including static setups [12:17] Yes, indicate that we'll vote next Tuesday. [12:17] Is there a sense that the current draft will pass? [12:17] scop: And it even made a lot of sense [12:18] One problem is the "collection of past random notes" bit. [12:18] Is that supposed to become part of the draft, or is it something separate? [12:19] I think it's Ville's raw note collection [12:19] there's some value in some of those bits [12:19] actually, I think most of it is from Enrico [12:19] Right; the question is whether any of it needs to make it into the draft somehow. [12:19] more like future directions or enhancement ideas [12:19] Either as rationale or examples or something. [12:20] I'd leave them mostly out of the draft [12:20] I hope the semi-static stuff is part of the past, not the future ;) [12:20]  frankly, I stopped reading at the very moment I read UserRegistry [12:20]  :) [12:20] also, the %hint stuff doesn't seem helpful to me [12:20]  That's the semi-static stuff in a sheep's disguise ;) [12:20]  I guess you are aware that multiple package can share users [12:21]  I like the "Dynamically mapped users and groups" even for static entries [12:22]  Whenever we need a static entry like for the 60ish packages we currently use it just put it in "setup" [12:22]  thoughts where the leftover bits that aren't part of the draft should be moved? [12:22]  I have to agree that the "just build your own setup package" route seems  better and better to me. [12:23]  I'd rather not just bluntly remove them [12:23]  furthermore, I am missing a statement on uid/gid ranges for "local use" and "network wide use" [12:23]  Just append "Notes" to the name of the draft and move them there? [12:23]  http://fedoraproject.org/wiki/PackagingDrafts/UsersAndGroupsBrainstorming [12:23]  racor: Does that distinction exist now? [12:24] racor: see item 3 [12:24] tibbs: Somehow, -r created ids are always local [12:25] tibbs: network wide, no, no concept that I am aware about [12:25] Unless they already exist in "setup" [12:25] Have a network wide customized "setup" [12:26] I think it'll work no matter what method one uses to create them beforehand [12:26] thimm: even setup is only fedora-wide [12:27] scop: I would make the "-d HOMEDIR, -s SHELL (often /sbin/nologin), and -c COMMENT options" mandatory [12:27] racor: Not your own "setup" [12:27] thimm, agreed [12:27] racor: You can predefine any entries matching your local setup in the "setup" package [12:28] thimm: doesn't matter if I could, nobody forces one to use it [12:28]  Why should you be forced? [12:28] The idea is to be flexible enough to use the id you like [12:29] thimm: I use a traditional "-r is local" the rest in yp/nis approach [12:29] Sorry, I misunderstood "local" [12:30] Yes, I think system accounts should always be local, e.g. no NIS/LDAP,  IMHO [12:30] I meant local in the sense of "machine-wide", in contrast to "unified uids/gids" across a network [12:30] Unified uid/gid can be done w/o LDAP/NIS if you share the same "setup" across your network [12:30] I think our only concern is that packages create their UIDs below UID_MIN unless they already exist. [12:31] thimm: are you referring to the setup.rpm or to "setup" in the sense of "network setup" [12:31] ? [12:31]  "setup" = setup rpm package [12:32] OK, no misunderstanding. I've never actively used the setup.rpm but am using yp/nis hosted on an arbitrary OS [12:32] <-- [splinux]  has left this server (Read error: 104 (Connection reset by peer)). [12:32] That would work, too, but I wouldn't make that a recommended setup [12:33] The issue that comes up is when you're kickstarting a system; it's generally not hooked up to your network authentication system at that point. [12:33] Rebuilding setup is at least a way to force a UID at initial install time. [12:34] The alternative is some major hacking on anaconda. [12:34] Maybe it isn't that much hacking [12:34] But it would open a can of worms [12:35] Certainly more hacking than we as a committee are able to mandate, that's for sure. [12:35] :) [12:35]  tibbs: Test for fesco reading the reports? [12:35]  "The fpc mandated anaconda to be rewritten in ruby following the new gems guidelines" [12:36]  packages that create users should probably create and own the home dir specified for the user? [12:36]  Makes sense [12:36]  Although some are using "/" [12:37]  hm [12:37]  Hmm, my gut feeling isn't comforatble about "/" as home [12:38]  ditto [12:38]  $ grep :/: /etc/passwd [12:38]  nobody:x:99:99:Nobody:/:/sbin/nologin [12:38]  dbus:x:81:81:System message bus:/:/sbin/nologin [12:38]  distcache:x:94:94:Distcache:/:/sbin/nologin [12:38]  nscd:x:28:28:NSCD Daemon:/:/sbin/nologin [12:38]  avahi:x:70:70:Avahi daemon:/:/sbin/nologin [12:38]  haldaemon:x:68:68:HAL daemon:/:/sbin/nologin [12:38]  rpc:x:32:32:Portmapper RPC user:/:/sbin/nologin [12:39]  some also have /bin and /sbin [12:39]  Yes, I dislike / for any home directory, although I'm not sure what would be better. [12:40] /tmp ? [12:40] I think that's worse. [12:40] yeah, .bash_history ... [12:40] Anyone can write there, after all, so who knows what kind of weird problems could crop up. [12:41] Something under /var/lib or /var makes more sense to me. [12:41] Or /var/empty, perhaps. [12:41] or /srv/[...] [12:41] I'll add something to the draft along these lines for next week [12:43] .bash_history: None of the accounts other than mysql and psql ever log in [12:43]  I guess the point is that it should be created specifically for that user and should have restrictive permissions. [12:43] Like no shell? [12:44] thimm, su -s /bin/bash - foo [12:45] exit [12:45] Umm, wrong window. [12:45] :) [12:46]  Just playing with su. [12:46]  Anyway, anything else? [12:46]  * scop has nothing [12:46]  Requires: initscript? [12:47]  thimm, ? [12:47]  I see no reason why that should be any different than Requires: filesystem [12:48]  See Matthias' post on list [12:48]  tibbs: see Enrico's reply [12:48]  If it's going to be discussed on list I see no reason to even bring it up here, then. [12:50]  OK, if there's nothing else we could close early this week I guess [12:50]  but for the record: I really like Ville's draft, and he seems to miss some feedback :) [12:50] thanks [12:51] and I'm actually pleased that there hasn't been much feedback :) [12:51]  There's a big flamewar buried in there somewhere.  Keep trying; it will happen. [12:52]  you're probably right [12:56]  anyway, thanks everyone, I'll have to run now [12:56]  Well, this should be an easy summary.