From Fedora Project Wiki

Revision as of 03:21, 21 December 2008 by Wikibot (talk | contribs) (Packaging/Minutes20070508 moved to Packaging:Minutes20070508: Moving Packaging Pages to Packaging Namespace)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Fedora Packaging Committee Meeting of {2007-05-08}

Present

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:

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.

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