From Fedora Project Wiki

Fedora Packaging Committee Meeting of {2007-06-26}

Present

  • 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

The following proposal was considered:

Other Discussions

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

  • What files should be allowed to be placed in /srv/ ?
  • Some packages explicitly place things in /srv
  • Tabled until next week in order to get thimm's opinion.

IRC Logs

[12:05]  * abadger1999 is here
[12:05]  * tibbs here
[12:05]  <f13> spot is feeding the kitties.
[12:05]  <racor> racor is here
[12:05]  <rdieter> here
[12:05]  * spot is back
[12:05]  <rdieter> wait... getting more coffee first...
[12:06]  --> scop has joined this channel (n=scop@cs181043142.pp.htv.fi).
[12:07]  <spot> lutter: ?
[12:08]  <spot> ok, everyone is here except lutter and thimm
[12:08]  <spot> rdieter: back with coffee yet?
[12:08]  <rdieter> here (yes)
[12:08]  * scop is half here
[12:10]  <f13> spot: what do you have for us fearless leader?
[12:10]  <spot> alright, lemme find the URL for item 1
[12:11]  <tibbs> http://fedoraproject.org/wiki/PackagingDrafts/CommitIDs ?
[12:11]  <spot> http://fedoraproject.org/wiki/PackagingDrafts/CommitIDs
[12:11]  <spot> yep. thats what i was looking for. :)
[12:11]  <tibbs> We discussed this last week and I altered the draft according to those discussions.
[12:11]  <spot> it looks reasonable to me.
[12:11]  <scop> s/YYYMMDD/YYYYMMDD/
[12:12]  <spot> indeed.
[12:12]  <rdieter> looks like we have winner
[12:12]  <spot> ok folks, lets vote
[12:12]  <f13> what's the 16char limit?  a full sha1?
[12:12]  <scop> full sha1 is 40 chars, no?
[12:13]  <f13> if so, what's the "16" in reference to?  Just a stab at a limit?
[12:13]  <rdieter> f13: a-quasi arbitrary limit, yes
[12:13]  <spot> i think its a reasonable limit
[12:13]  <straw> i've used that same convention locally :)
[12:13]  <f13> is there any reason why it couldn't be 8?
[12:14]  <f13> 16 is a /long/ string (:
[12:14]  <tibbs> The problem is that if you put no limit then people will encode full git sha1s.
[12:14]  <tibbs> 8 doesn't even allow for svn and a commit number on an active tree.
[12:15]  <f13> k
[12:15]  <spot> +1 on the draft
[12:15]  <rdieter> +1
[12:15]  <straw> +1
[12:15]  <abadger1999> +1
[12:15]  <tibbs> +1
[12:16]  <tibbs> For the record, who is straw?
[12:16]  <scop> +1
[12:16]  <scop> (with the YYYY correction, that is)
[12:16]  <tibbs> I already changed the YYY thing.
[12:16]  <straw> tibbs: i'm a livna contrib and kde user
[12:17]  <f13> +1
[12:18]  <racor> +1
[12:18]  <tibbs> I just need to be sure that one of the voting members didn't change their nick when I'm counting votes.
[12:18]  <scop> I'm not sure if we want to encourage abbreviated git hashes, they seem pretty pointless to me and I'd remove the example
[12:18]  <scop> but I don't mind that much, still +1
[12:18]  <straw> tibbs: oh. nope
[12:18]  <f13> scop: I think the abbreviated git hash is fine, so long as the full hash is in the spec file along with the directions on how to get that hash out of git
[12:18]  <tibbs> It was the actual use abbreviated git hashes that necessitated the draft in the first place.
[12:19]  <racor> FWIW: I am not sure about the YYYYMMDD thing, they are very meaningful wrt. svn and git
[12:19]  <-- lutter has left this server ("Leaving.").
[12:19]  <racor> add ... not very meaningful ...
[12:19]  <tibbs> The date is certainly meaningful.
[12:20]  <rdieter> meaningful to rpm/packaging...
[12:20]  <racor> not with svn, only the number matters
[12:20]  <f13> it's no more/less meaningful for cvs.  Just because you did the checkout on <date> doesn't mean you didn't request a tag or a branch
[12:20]  <tibbs> The date is not intended as information to use in reproducing the checkout.
[12:20]  <f13> and since the versioning keys off the alphatag which is before the date....
[12:20]  <tibbs> It's intended for humans.
[12:21]  <racor> f13: right, but unlike with cvs where you normally check out "by date" with svn, you check out "by id"
[12:21]  <straw> racor: that's accounted for
[12:21]  <f13> racor: if you're only talking about CVS head sure, same with SVN you can check out SVN "head" at any date too
[12:22]  * spot waits for the semantics to die down
[12:22]  <f13> the point is that the date is rather meaningless for all scms, the important thing is marking in the spec how the snapshot was taken
[12:22]  <racor> f13: ... and receive an id, which will be what you'll be using in future
[12:23]  <spot> Next item: Files in /srv
[12:23]  <spot> What files should be allowed to be placed in /srv/ ?
[12:23]  <racor> f13: I am not aware about any project using svn, which checks out "by date".
[12:23]  <f13> all I'm saying is that date is just as meaningfull/less for all scms involved.
[12:23]  <f13> because checking out "by date" in teh morning of a CVS project doesn't mean you'll get the same thing that afternoon on the same date.
[12:24]  <f13> spot: that's my topic, I'm really not sure what the FHS means to do with /srv/
[12:24]  <f13> spot: and I'm /really/ not sure if packages, such as lighttpd, should be creating /srv/www/lighttpd/ directories/files
[12:24]  <tibbs> Do we currently have packages placing things in /srv?
[12:24]  <scop> http://www.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM
[12:24]  <f13> tibbs: yes
[12:25]  <tibbs> suckage, then.
[12:25]  <spot> the FHS seems to imply that /srv is for "site-specific data"
[12:25]  <spot> which is horribly vague
[12:25]  <f13> yeah
[12:26]  <rdieter> I think it's ok for use.
[12:26]  <f13> This setup will differ from host to host. Therefore, no program should rely on a specific subdirectory structure of /srv existing or data necessarily being stored in /srv. However /srv should always exist on FHS compliant systems and should be used as the default location for such data.
[12:26]  <spot> but it does give www/ftp as examples of top level directories
[12:26]  <spot> i think the lighttpd use is acceptable
[12:26]  <f13> since it could differ, I'm not sure packages should be stomping in there and staking claim
[12:26]  <rdieter> "should be used as the default location for such data." worksforme.
[12:27]  <rdieter> ah, snipping is bad sometimes, nevermind.
[12:27]  <scop> I think SUSE interprets /srv strictly for local data which packages must not touch
[12:27]  <straw> i've got vdr creating and owning directories in /srv
[12:27]  <scop> FWIW
[12:27]  <racor> suse uses it as common replacement, where Fedora/RH has used /var/www, /var/ftp etc.
[12:27]  <rdieter> too bad Axel's not here today, he's got some (strong) opinions about /srv usage.
[12:28]  <f13> I'm OK waiting until he's around
[12:28]  <f13> I just noticed it when I was playing with lighttpd
[12:28]  <spot> alright, lets shelve this for now
[12:28]  <spot> (bittorrent is using it too)
[12:28]  <rdieter> trac's config files reference using /srv too (not actual using it tho)
[12:28]  <spot> ok next item:
[12:28]  <spot> http://fedoraproject.org/wiki/PackagingDrafts/UsersAndGroups
[12:28]  <spot> (i know, i know, pain)
[12:29]  <spot> the only showstopper i have against the current draft is that it allows %pre to fail
[12:29]  <tibbs> spot: What happened to your separate draft?
[12:29]  <spot> tibbs: it got torn apart six ways from sunday
[12:29]  <tibbs> Right, but did you withdraw it?
[12:30]  <spot> yeah.
[12:30]  <rdieter> spot: +1, %pre failures is a showstopper for me as well.
[12:30]  <scop> I think we already came to a conclusion (myself included) that allowing %pre to fail is a no go
[12:30]  <spot> scop: ok, can you fix up your draft so pre doesn't fail?
[12:30]  <scop> I just haven't updated the draft yet while I was watching what happens with the alternative proposal
[12:30]  <scop> spot, yes
[12:30]  * rdieter liked spot's draft.
[12:31]  <spot> I still think there is a lot of good points in my draft, and that it solves more of the problems than scop's draft.
[12:31]  <spot> but...
[12:31]  <spot> it is a lot more complicated
[12:31]  <tibbs> The issue is complicated.
[12:32]  <f13> so complicated that I haven't paid attention to it at all
[12:33]  <racor> sorry, my time's up for today, I've got to leave.
[12:33]  <spot> in a perfect world, rpm would handle user/group creation on its own
[12:33]  <spot> and we'd just say "Provides: user(foouser)"
[12:33]  <scop> I agree
[12:33]  * rdieter nods
[12:33]  <tibbs> Has anyone asked the rpm folks about that?
[12:34]  <rdieter> and Requires: group(foogroup) ...
[12:34]  <spot> i came to the conclusion over vacation that I'd rather push rpm towards that than build a massive emulating hack (my draft)
[12:34]  <straw> i've noticed the user/group is often left behind once the package is removed
[12:34]  <tibbs> It had better be left behind.
[12:34]  <scop> straw, *always*, intentionally, see the draft
[12:34]  <rdieter> straw: right, intentional.
[12:34]  <straw> i thought so
[12:35]  <straw> ah, i see
[12:35]  <spot> the only other missing item was implementing ranges for shadow-utils
[12:35]  <scop> was there a conclusion on -packaging that "getent" would be better than "id" and -f to groupadd?
[12:35]  <spot> id is NIS enabled
[12:36]  <spot> but the groupadd check should use something NSS enabled
[12:36]  <spot> (NSS, not NIS)
[12:36]  <rdieter> s/NIS/NSS/ ?
[12:36]  <rdieter> :)
[12:37]  <spot> how about we do this
[12:37]  <scop> is groupadd -f not NSS enabled?
[12:37]  <rdieter> fwiw, isn't relying on system accounts being non-local kinda scary?
[12:37]  <spot> rdieter: yep.
[12:37]  <rdieter> so why do we care again?
[12:37]  <rdieter> (just checking for existence/conflicts?)
[12:38]  <spot> if it exists, don't make it.
[12:38]  <rdieter> ok
[12:38]  <spot> theres still a corner case where "amanda" exists and inherits all of those files
[12:38]  <tibbs> "non-local" could be "shared between different virtual hosts on the same machine", so there are situations where it's not terribly scary.
[12:38]  <tibbs> spot: The only solution I can think of there is to prefix system users somehow.
[12:39]  <spot> tibbs: that just makes it harder to trigger, not a true solution
[12:39]  <tibbs> There is no true solution other than namespaces.
[12:39]  <spot> an overworked admin on a large system creates a user "fedora-amanda"
[12:40]  <rdieter> tibbs: I think I like that, using some sort of system-* namespace.  Not sure how practicle it is in practice.
[12:40]  <scop> I think I'd hate that :)
[12:40]  <tibbs> Unfortunately is screws the default ps output.
[12:40]  <tibbs> But so does "haldaemon".
[12:40]  <spot> daemon-* was something else I thought of.
[12:40]  <spot> but not all of these are daemons
[12:41]  <tibbs> DAEMON\SYS$\HTTPD
[12:41]  <spot> so, i'm going to look at shadow-utils this afternoon
[12:41]  <spot> and try to implement ranges
[12:42]  <spot> 0-99 for static ids, 100-499 for dynamic ones, 500-... for users.
[12:42]  <spot> so that you can specify "use a free id in this range if one exists"
[12:43]  <spot> then at least, we can avoid stepping in user range by accident
[12:43]  <tibbs> It's sad that we have, what, 32 bits of UID space and yet we can only use so little of it.
[12:43]  <scop> didn't Enrico implement some --hint patches to shadow-utils?
[12:43]  <tibbs> spot: What happens when no free ID in the range exists?
[12:44]  <scop> hm, but that could be orthogonal to ranges
[12:44]  <spot> it exits
[12:44]  <tibbs> You can't fail, though.
[12:44]  <spot> having useradd exit and having %pre fail are different items
[12:44]  <warren> spot, there will be a written users-in-packages standard?
[12:44]  <scop> what do people think of failing in %pretrans instead of %pre?
[12:44]  <spot> warren: this what we're working on.
[12:45]  <tibbs> True, but neither failure mode is good is good at all.
[12:45]  <warren> great!
[12:45]  <spot> scop: i have no idea if that is safe in a transaction
[12:45]  <rdieter> scop: maybe, I thought we had come up with a reason against that too, but can't think of it now... :)
[12:46]  <spot> the problem is that we really need to be careful when failing a package install
[12:46]  <spot> because it can leave a system in an ugly state.
[12:46]  <scop> if %pretrans works as I expect, it would prevent the whole transaction
[12:46]  <spot> but if a failure in %pretrans stops the entire transaction...
[12:46]  <rdieter> I've got an idea how to help there, (in my head awhile), I'll post something to ml later.
[12:47]  <scop> not sure what that means in kickstart and friends situations though
[12:47]  <spot> scop: can you do some tests to see if it works in manual (rpm cmdline) and yum scenarios?
[12:47]  <scop> yes
[12:47]  <spot> kickstart should be covered by yum
[12:47]  <scop> unless rdieter had something similar in mind?
[12:48]  <rdieter> naw, I was thinking more about recovering/fixing system-ids after biffed useradd...
[12:48]  <scop> ok
[12:48]  <spot> ok, so lets test these items, i'll work on shadow-utils ranges
[12:48]  <spot> and we'll revisit next week
[12:49]  <spot> last item: Static Library Update
[12:49]  <spot> did FESCo ratify that?
[12:49]  <tibbs> It was ratified.
[12:49]  <spot> ok, i'll move it to writeup
[12:49]  <spot> any other topics for today?
[12:50]  <rdieter> I was thinking of adding more stuff to %cmake macro... stuff like:
[12:50]  <rdieter> -DSYSCONF_INSTALL_DIR=%{_sysconfdir}
[12:50]  <rdieter> -DSHARE_INSTALL_PREFIX=%{_datadir}
[12:50]  <rdieter> -DINCLUDE_INSTALL_DIR
[12:51]  <rdieter> oops, -DINCLUDE_INSTALL_DIR=%{_includedir}
[12:51]  <rdieter> -DLIB_INSTALL_DIR=%{_libdir}
[12:51]  <rdieter> hit this when working more on kde4 packaging.
[12:51]  <spot> that all seems reasonable (with my limited knowledge of cmake)
[12:51]  <spot> draft it, pls.
[12:51]  <rdieter> ok, just wanted to see if anyone would yell: That is just so stooopid.
[12:51]  <scop> :)
[12:52]  <spot> i suspect you're the resident cmake expert. :)
[12:52]  <nirik> quick question: two items that are minor, don't know if they would be worth writing up and possibly adding to guidelines...
[12:52]  <scop> shoot
[12:52]  <rdieter> spot: not really, I'm more of a cmake-trainee atm.
[12:52]  <nirik> 1. Note that you can't approve your own package in a review, or approve someones submitted package and maintain it (which is similar to the first case) ?
[12:52]  <rdieter> oops
[12:53]  * rdieter has done the latter a few times... (became comaintainer after review, or is that ok)
[12:53]  <scop> -ENOTPACKAGINGTHEORY :)
[12:53]  <spot> i'm not sure thats FPC, more FESCo
[12:53]  <spot> i moved all of the "how to review" text out of Packaging/ a while back
[12:53]  <nirik> ok, just wondered if it was a guidelines issue, but I guess you are right.
[12:53]  <rdieter> nirk: and 2?
[12:54]  <nirik> 2. attribution. Should there be a note that if you grab a spec from another repo and submit it you MUST attibute it to the author (ie, leave their changelog at least?)
[12:54]  <spot> eh. MUST is a big one there. SHOULD.
[12:55]  <rdieter> nirik: that's just common courtesy, don't think it's worth making a MUST item...
[12:55]  <f13> should.
[12:55]  <scop> leaving the whole changelog might not be too useful
[12:55]  <spot> i've taken horrible horrible packages from other repos and cleaned them up
[12:55]  <f13> Technically specs are source code and thus all the "fun" is attached.
[12:55]  <spot> to the point where about all that was left of the original package _was_ the changelog entries
[12:55]  <scop> "- First build, based on $foo's work"
[12:55]  <nirik> true, should would be fine... we should at least ack that someone else did the orig package tho I think.
[12:56]  <spot> I'd vote +1 on referencing it in the changelog somehow
[12:56]  <spot> either by preserving the old entries or as scop suggested
[12:56]  <spot> as a SHOULD
[12:56]  <scop> I'd vote +1 for that too
[12:56]  <straw> if the spec does something special i may not have come up with, i attribute
[12:57]  <spot> nirik: feel free to draft that one. it looks like it would pass.
[12:57]  <nirik> It's kinda minor, but I think making sure we have people do that would make us better community members of the rpm packagers at large...
[12:57]  <nirik> ok, can do that.
[12:57]  <spot> anyone else before we close out for today?
[12:57]  <straw> if it's just your average spec, what's the point
[12:57]  <rdieter> straw: to be ince? :)
[12:58]  <rdieter> nice even...
[12:58]  <tibbs> Do we really want to write common courtesy into the guidelines?
[12:58]  <tibbs> Not that I have anything against common courtesy, of course.
[12:59]  <nirik> you are building on someone elses work, shouldn't you say that at least?
[12:59]  <spot> i think this item is something that new packagers might not think of.
[12:59]  <rdieter> tibbs: in general, no, but something like attribution,changelog is probably worthy of mention...
[12:59]  <spot> so its worth a mention as a SHOULD
[12:59]  <nirik> I suppose there could be a license issue... if some place has a weird license on their spec and it gets re-used for a fedora package.
[13:00]  <nirik> (not that I know of any place that doesn't distribute their specs just fine)
[13:00]  <straw> i've never seen a .spec with a license attached
[13:01]  <rdieter> (not serious, but...) maybe Guildelines preamble/prereq, including: SHOULD: be nice, use common courtesy, don't be stupid, don't be an ass.
[13:01]  <spot> straw: SuSE licensed their specs for years
[13:01]  <spot> i dont know if they still do
[13:01]  <straw> holy...
[13:01]  <straw> SuSE specs give me nightmares
[13:01]  <rdieter> not that anyone would want to re-use SuSE's specs... :)
[13:01]  <skvidal> %why %not %rdieter?
[13:02]  <straw> heh
[13:02]  <spot> %rude_comment %jokeaboutyourmother %random_german_exclamation
[13:02]  <nirik> it's hard to legislate good behavior... but I think this is the case where it would be nice to mention for new packagers who might not think about it.
[13:02]  <rdieter> %ha, _forgot_to_include_any_BuildRequires
[13:03]  <spot> %specmacro
[13:03]  <spot> EOF
[13:03]  <skvidal> buildreqs are for sissies
[13:03]  <straw> stop it! the bad dreams...
[13:03]  <spot> ok, i'm hungry and i have to go buy boxes and tape.
[13:03]  * spot ends the meeting
[13:03]  <spot> thanks all.
[13:04]  <skvidal> spot: enjoy the move!
[13:05]  <straw> thanks all. this was a first for me after ~2 years of writing for my own local repo
Retrieved from "https://fedoraproject.org/w/index.php?title=Packaging:Minutes20070626&oldid=66553"