Packaging:Minutes20071120

Fedora Packaging Committee Meeting of {2007-11-20}

Announcement

FPC returns to its two-week schedule; the next meeting will be Tuesday, December 4th at 17:00UTC.

Present

• JasonTibbitts (tibbs)
• JesseKeating (f13)
• RalfCorsepius (racor)
• RexDieter (rdieter)
• TomCallaway (spot)
• ToshioKuratomi (abadger1999)
• VilleSkyttä (scop)

• NicholasMailhot (nim-nim)

Votes

The following proposal was considered:

• Policy for font packages: http://fedoraproject.org/wiki/PackagingDrafts/FontsPolicy
• Accepted (with changes) (5-0)
• Voting for: spot rdieter abadger1999 scop tibbs
• Abstaining: racor
• Some notes:
• There are components of the proposal which go beyond packaging policy and are not considered by FPC. This includes the CompsPolicy document and sections of the draft relating to grouping or comps. These should be discussed by FESCo.
• http://fedoraproject.org/wiki/PackagingDrafts/FontsSpecTemplate was approved as part of this proposal with the caveat that the scriptlets be prevented from failing.

Other Discussions

The following additional item was discussed; see the logs for full details.

• Three volunteers expressed interest in joining the committee; spot will poll the membership and we'll decide whether to expand the committee or rotate through some members on-list.

IRC Logs

[11:03]  * spot is here
[11:03]  * tibbs here
[11:05]  <spot> so, i see rdieter, tibbs, and me...
[11:05]  <tibbs> Hmmm.
[11:06]  <spot> abadger1999, f13, lutter, racor, scop?
[11:06]  <scop> pong
[11:06]  <abadger1999> Here
[11:06]  <spot> while we give f13, lutter, and racor a moment
[11:07]  <spot> there are three fonts related items on: http://fedoraproject.org/wiki/Packaging/GuidelinesTodo
[11:07]  <racor> pong
[11:07]  <spot> if you haven't read them yet, now would be an excellent opportunity
[11:07]  <tibbs> Looks like that page needs an update; eggs should be "writeup" or moved to "resolved items".
[11:08]  <spot> tibbs: yep, writeup, i thinlk
[11:08]  <abadger1999> tibbs: I'll fix that.  Thanks.
[11:08]  <spot> abadger1999: unless you've written it up, of course.
[11:08]  <abadger1999> spot: Yep.  It's written up.
[11:09]  <tibbs> spot: Are you comfortable with the "Legal considerations for fonts" page?
[11:09]  <spot> tibbs: yes, i helped them write it
[11:09]  <tibbs> OK, good.
[11:11]  <spot> alright, lets start with: http://fedoraproject.org/wiki/PackagingDrafts/FontsPolicy
[11:12]  <spot> it looks ok to me.
[11:12]  <spot> +1
[11:13]  <rdieter> +1
[11:13]  <abadger1999> Looks good to me and Nicolas is the right person to be spearheading that.  +1
[11:13]  <scop> +1, although there's not much packaging related stuff in it
[11:14]  <tibbs> +1
[11:14]  <spot> thats +5, racor, would you like to vote?
[11:15]  <racor> i am still reading ....
[11:15]  <spot> ok, we'll wait for you. :)
[11:15]  <racor> my vote: 0
[11:15]  <spot> mmkay.
[11:15]  <spot> next item: http://fedoraproject.org/wiki/PackagingDrafts/FontsComps
[11:15]  <racor> i find it too detailed and partially biased
[11:16]  <spot> fwiw, i don't disagree with the Comps stuff, but i'm not sure the FPC is responsible for comps behavior
[11:16]  <scop> ditto
[11:17]  <spot> i think we can just hand this back to the SIG to determine on their own, or to FESCo
[11:18]  <racor> spot: ack
[11:18]  <rdieter> can we at least say the FPC is ok with the strictly packaging-related bits?
[11:18]  <spot> are there any in that FontsComps draft?
[11:18]  <abadger1999> Err.. you know that this is at the end of the first proposal as well?
[11:18]  <rdieter> it talked about dependencies/Requires.
[11:19]  <abadger1999> (Under Grouping)
[11:19]  <spot> abadger1999: yeah.
[11:19]  <rdieter> or wait, brain still stuck on FontsPolicy, not Comps
[11:19]  <spot> abadger1999: i think he meant to leave it off and forgot to
[11:19]  <spot> lets toss that back to the Font SIG and let them decide for themselves
[11:20]  <spot> Third item: http://fedoraproject.org/wiki/PackagingDrafts/FontsSpecTemplate
[11:20]  <spot> One notable item for the SpecTemplate
[11:20]  <scop> "|| :" missing from scriptlets
[11:20]  <spot> the post/postun don't match http://fedoraproject.org/wiki/PackagingDrafts/FontsSpecTemplate
[11:21]  <spot> err... scripletsnippets
[11:21]  <spot> scop: exactly.
[11:21]  <spot> I know that Nicolas feels... strongly about the fact that the || : is not needed
[11:21]  <spot> his opinion is that he does want the %post / %postun to fail in those cases.
[11:22]  <scop> I don't agree with that offhand
[11:22]  <spot> neither do i.
[11:23]  <spot> i think we want to prevent %post / %postun from failing whenever possible, as we previously mandated.
[11:23]  <rdieter> yup
[11:24]  <spot> so, aside from that change, everything else looks ok to me.
[11:24]  <tibbs> I'm confused; what purpose would he see in having %post fail?
[11:25]  <racor> I guess, it's simply "seeing the bugs"
[11:25]  <tibbs> So don't redirect to /dev/null.
[11:25]  <spot> i don't think these commands are redirected anyways.
[11:27]  <racor> a detail I am not comfortable with is the if [ -x %{_bindir}/fc-cache ] ; inside of the scriptlets
[11:27]  <racor> why not using Requires(pre, ...)?
[11:27]  <spot> racor: the logic there is that he doesn't want to Require: any specific set of font tools
[11:28]  <spot> as many of these fonts work fine in several places
[11:28]  <racor> spot: IMO, a mistake
[11:28]  <tibbs> Why?
[11:28]  <spot> "Execution of stack-specific helpers in scriptlets is allowed, as long as it's conditioned on the presence of those helpers on the system, does not force their installation for the font package, and does not block package installation in their absence."
[11:29]  <spot> http://fedoraproject.org/wiki/SIGs/Fonts/Packaging/Policy#no-handler-deps
[11:29]  <racor> imagine not having %{_bindir}/fc-cache installed at some time
[11:29]  <racor> then to install it later,
[11:29]  <racor> result: broken font-caches
[11:29]  <scop> nope
[11:29]  <scop> fontconfig's %post runs it
[11:30]  <racor> scop: I don't understand
[11:30]  <spot> fontconfig provides fc-cache
[11:30]  <spot> it also runs fc-cache in its own post
[11:31]  <spot> so, if you install fontconfig later, fc-cache will get run and everything is cached.
[11:31]  <spot> the font scriptlets are not package specific, its just triggering a system cache reset
[11:32]  <spot> in their specific case, they have a need for a bit of careful flexibility, and I'm inclined to let them go ahead with it.
[11:32]  <racor> spot: are they? I see fontdir as argument to the call to fc-cache inside of the scriptlets
[11:33]  <rdieter> racor: as long as fontconfig is configured to find the new fonts, all is (still) well.
[11:33]  * spot double checks fontconfig quickly
[11:33]  <rdieter> if fontconfig can't find the fonts, they won't work anyway. :)
[11:34]  <spot> # Force regeneration of all fontconfig cache files
[11:34]  <spot> # The check for existance is needed on dual-arch installs (the second
[11:34]  <spot> #  copy of fontconfig might install the binary instead of the first)
[11:34]  <spot> # The HOME setting is to avoid problems if HOME hasn't been reset
[11:34]  <spot> if [ -x /usr/bin/fc-cache ]  && /usr/bin/fc-cache --version 2>&1 | grep -q %{ver$
[11:34]  <f13> hrm, seems I misfiled the meeting reminder.
[11:34]  <spot>   HOME=/root /usr/bin/fc-cache -f
[11:34]  <spot> fi
[11:34]  <scop> yep, I suppose no need to refresh everything in the font configuration if we know only one dir has been changed/added
[11:34]  <scop> (that's why the dir argument in font package scriptlets, that is)
[11:35]  <spot> so, fontconfig is definitely handling the case that you're worried about, racor
[11:36]  <racor> OK, I'll trust you for the moment, ...
[11:36]  <spot> so, with the scriptlets fixed to not fail (aka || : ), i'd vote +1 on this draft.
[11:37]  <f13> was that talked about in this meeting already?
[11:37]  <f13> (the scriptlets not failing contengency)
[11:37]  * spot sends f13 the backlog in private msg
[11:38]  <f13> hrm.
[11:38]  <f13> I feel that's a much bigger issue so yeah, lets just make this conform for now.
[11:38]  <racor> another minor nit: "Group: User Interface/X"
[11:38]  <tibbs> You know, if I were reviewing one of these packages, I'd ask "Why not just %{fontdir} instead of the last three lines of the %files list?"
[11:38]  <spot> tibbs: yeah, i wondered about that. only thing I can think is to catch non-fonts in those dirs for some reason
[11:39]  <spot> racor: last time i checked, we don't really care what anyone puts in Group:. :)
[11:39]  <racor> aren't fonts supposed to be independent from X? Wouldn't be "Group: User Interface/Fonts" be better?
[11:39]  <f13> *cough*
[11:40]  <f13> FPC doesn't give a rats ass what is in Group.  It could say "Bobs/your/uncle" for all I care
[11:40]  <tibbs> If we're making something up, I'd have to agree, but then you might as well put "Group: Who/Cares"
[11:40]  <spot> User Interface/X is in /usr/share/doc/rpm-4.4.2.2/GROUPS
[11:40]  <racor> f13: thank you for your insights.
[11:40]  <spot> i'd guess thats why they chose it.
[11:40]  <tibbs> But it is a specfile template, and Group: does have to be there for the build to succeed.
[11:41]  <f13> If I remember correctly, we voted that the extent we care about Group is that it exists, until rpm can handle it notn being there.
[11:41]  <spot> f13: thats right.
[11:41]  <abadger1999> tibbs: I'm guessing the spec template is reflecting this: %{_datadir}/fonts is owned by the filesystem package -- Once bz302141 is closed.
[11:42]  <tibbs> abadger1999: But %{fontdir} is defined by the package as being gelow %{_datadir}/fonts.
[11:42]  <tibbs> Erm, below.
[11:42]  <nim-nim> hi
[11:43]  <nim-nim> spot asked me to pass
[11:43]  <spot> nim-nim: can you clarify why the spec template uses %dir %{fontdir} .... instead of just %{fontdir}/
[11:43]  <racor> i don't see what's wrong with multiple dir ownerships, we had discussed this long time ago.
[11:43]  <spot> racor: this isn't even a multiple dir ownership case
[11:44]  <racor> no hierarchy - multiple owners
[11:44]  <spot> no, no.... see, its like this
[11:44]  <spot> %{fontdir} evaluates to /usr/share/fonts/foo
[11:44]  <spot> the fonts-foo package needs to own /usr/share/fonts/foo and all fonts in it
[11:44]  <spot> the spec template is doing:
[11:44]  <nim-nim> in a font package case it's easy to do an explicit file list rather than relying on %dir
[11:44]  <spot> %dir /usr/share/fonts/foo
[11:45]  <spot> then /usr/share/fonts/foo/*.ttf
[11:45]  <spot> nim-nim: yes, but you only need to do:
[11:45]  <nim-nim> so %dir +  /usr/share/fonts/foo/*.ttf makes sure you're not packaging the wrong bits by mistake
[11:45]  <spot> %{fontdir}/
[11:45]  <spot> that will achieve the same end result.
[11:45]  * rdieter is ok with either way
[11:46]  * spot admits it is nitpicking
[11:46]  <tibbs> I prefer simplicity in templates, personally.  Complexity gets blindly copied when there's no point to doing so.
[11:46]  <nim-nim> %{fontdir}/ means that packagers that just copy files from zip archives without looking at them will ship unneeded files in %fontdir
[11:47]  <spot> its really two lines vs one, and the rationale for two is ok by me.
[11:47]  <rdieter> tibbs: +1.  packager's discretion, as long as the right stuff gets packaged, doesn't matter really.  the guidelines should use the simpler example tho, imo.
[11:47]  <nim-nim> but I admit that's mainly a personal preference
[11:47]  <spot> the spec template is just a template
[11:47]  <f13> I think going for the more simple solution, and relying upon the overall guideline that what's int he package should be reviewed for relevance.
[11:48]  <f13> er, I think that's the proper method.
[11:48]  <racor> Erm, I was referring to abadger1999 remark on %{_datadir}/fonts. This can have multiple owners, no need to pester filesystem
[11:48]  <spot> nim-nim: the other concern we have with the template is that the %post/%postun scriplets don't have || :, to prevent %post/%postun from failing
[11:48]  <f13> racor: aren't we still hindered by removal bugs?
[11:48]  <nim-nim> spot: for the other concern I think I've made my opinion abundantly clear :p
[11:49]  <spot> nim-nim: we're a little unclear on why you want %post/%postun to be able to fail
[11:49]  <racor> f13: no idea what you are talking about. multiple dir owners are common practice in perl packages for ages.
[11:49]  <nim-nim> spot: if it does not fail you have users that think the transaction succeeded and report weird bugs
[11:50]  <nim-nim> and you have packages that do not notice they made a mistake
[11:50]  <f13> racor: IIRC when removing a set of packages that all own a dir, the removal order isn't ensured so bad things can happen, at least that's what's floating in my head every time multiple ownerships come up.
[11:51]  <scop> stderr should take care of that
[11:51]  * spot looks for his notes from when we discussed this originally
[11:51]  <racor> f13: right. multiple dir owner only work if all files and dirs are rpm owned. This applies to the perl packages.
[11:51]  <f13> nim-nim: output to stderr can be used for that, and such bugs should be caught before they're sent to the user.
[11:51]  <scop> if the scriptlets fail, the result is often rpmdb trash (dupe packages)
[11:51]  <f13> racor: lets discuss this later.
[11:52]  <nim-nim> f13: well the fact the transaction fails has so far insured the problem never hit non-rawhide users
[11:52]  <f13> nim-nim: the user can't really do anything to fix it anyway.
[11:52]  <f13> nim-nim: sorry, I don't buy that.
[11:52]  <f13> at least not as something that will scale into the future
[11:52]  <nim-nim> f13: it has scaled so far
[11:53]  <nim-nim> I mean we don't have many data points because only one person foobared his font package so far, and the fact the it resulted in transaction failures made rawhide users pester him so it was fixed asap
[11:54]  <nim-nim> I really don't see what not-failing the transaction would have accomplished
[11:54]  <nim-nim> in this case
[11:54]  <f13> you're (ab)using users to do your own qa work.
[11:54]  <f13> don't.
[11:54]  <nim-nim> I'm not
[11:54]  <spot> "Non-zero exit codes from scriptlets break installs/upgrades/erases so that no further actions will be taken for that package in a transaction (see scriptlet ordering below), which may for example prevent an old version of a package from being erased on upgrades, leaving behind duplicate rpmdb entries and possibly stale, unowned files on the filesystem."
[11:55]  <nim-nim> The packager who dumped a bad package on rawhide without checking did
[11:55]  <spot> That fact to me seems reason enough to require it.
[11:56]  <tibbs> I would much rather have a screwed font cache than a screwed RPM database.
[11:56]  <spot> tibbs: indeed.
[11:56]  <nim-nim> in the font package case the leftover files have almost always been overwritten by new files
[11:56]  <nim-nim> the user will have all sorts of problems, but not because of dangling files because the fonts weren't registered propserly for some reason in fc-cache
[11:57]  <rdieter> nim-nim: please just follow the existing guidelines, let's not make an issue of it, we have bigger things to worry about.
[11:57]  <nim-nim> in other words this bit failing means this font package install has totally failed and cloberred the old package version and nothing short of updating to a fixed package will heal the system
[11:57]  <racor> nim-nim: IMO, the real problem is, packages with broken scriptlets occasionally make it into release and then cause actual harm. Actual example from recent past: fc7's avahi
[11:57]  <racor> It kills FC7->FC8 upgrades
[11:58]  <spot> nim-nim: in the failure case, we can either get a clobbered font or a clobbered font and a corrupt rpmdb
[11:58]  <spot> which one seems like the lesser evil? :)
[11:58]  <nim-nim> racor: once again the only time a packager managed to get this part wrong in rawhide it was fixed precisely of the failing transactions
[11:59]  <nim-nim> else it would have languished in rawhide for weeks as is the usual case
[11:59]  <spot> nim-nim: people will still notice the failures
[11:59]  <nim-nim> and maybe even hit release
[11:59]  <f13> nim-nim: that's a failure on the SIGs part to properly qa your bits
[11:59]  * spot presumes the font sig is capable. :)
[11:59]  <racor> nim-nim: then you have been lucky - this time. Next time may differ
[11:59]  <f13> nim-nim: let's not trash people's rpmdb just for the sake of having an active check rather than a passive check.
[12:00]  <spot> with the scriptlets changed not to fail, I vote +1 on the template
[12:00]  <nim-nim> f13: the rpmdb is only trashed till an update to a working file is realised, right?
[12:00]  <racor> I join spot, +1 with change, -1 without.
[12:00]  <tibbs> spot +1
[12:01]  <scop> same as racor here
[12:01]  <spot> nim-nim: no, it can need to be regenerated in some really nasty corner cases
[12:01]  <racor> sorry boy, my times up, I gotta go ...
[12:01]  <spot> racor: thanks
[12:01]  <f13> +1 with change, -1 without.
[12:01]  * nim-nim will bow to FPC but will mercilessly redirect any problem this causes to the people who thought this was a good idea
[12:02]  <spot> nim-nim: eh, we're used to it. :)
[12:02]  <spot> i count +5, it passes with the change
[12:02]  * nim-nim will also note this change was not requested by anyone who actually packaged fonts
[12:03]  <spot> nim-nim: to be fair, i have a font package.
[12:03]  <rdieter> me too
[12:03]  <nim-nim> ok, I know where to redirect font QA then :p
[12:03]  <scop> did anyone besides Hans express interest towards joining FPC?
[12:03]  <f13> nim-nim: it's not about font packages, it's an overall decision the FPC has made wrt %pre/%post scripts.
[12:03]  <spot> nim-nim: please make that change to the draft before it goes before FESCO next week
[12:04]  <spot> scop: yes, we had three volunteers
[12:04]  <spot> Hans, Rathann, and Phil Knirsch
[12:04]  <tibbs> We should poll the current membership and see who wants to stay.
[12:05]  <spot> tibbs: yep. I will do that after the meeting.
[12:05]  <abadger1999> nim-nim: Are you interested in joining FPC?
[12:06]  <nim-nim> abadger1999: I don't think I have the time
[12:06]  <spot> any other last minute items before we adjourn for today?
[12:06]  <nim-nim> for example today spot caught me 2 min after I arrived home
[12:07]  <spot> going once.
[12:07]  <spot> going twice.
[12:07]  <tibbs> Nothing from me.
[12:07]  <spot> ok, thanks everyone. i'm going to go see if anything remains in the cafeteria for lunch.
[12:08]  <f13> later.
[12:09]  <scop> seeya
[12:10]  <tibbs> Crap; is the next meeting next week or two weeks hence?
[12:11]  <f13> week after next
[12:11]  <f13> we're every other week.
[12:11]  <f13> or did we make an exception for this week?
[12:11]  <f13> (which would explain why my phone was all confused)
[12:12]  <nim-nim> If it's in two weeks can you approve http://fedoraproject.org/wiki/PackagingDrafts/FontsSpecTemplate now ?
[12:13]  <spot> nim-nim: uh, we just did that
[12:13]  <spot> nim-nim: we approved it with the scriplet change
[12:13]  <spot> tibbs: lets say, meeting in two weeks
[12:13]  <spot> tibbs: get back on our schedule
[12:14]  <spot> it also helps us avoid Dec 25
[12:14]  <spot> (although, we're probably going to have to skip Jan 1 as well, i hope not to be sober enough to run FPC meetings that day)
[12:14]  <tibbs> Not again
[12:15]  <nim-nim> spot: so the current version is approved?
[12:16]  <spot> nim-nim: FESCO has to ratify all FPC decisions
[12:16]  <spot> nim-nim: after FESCO signs off on it it will be approved
[12:16]  <nim-nim> ah, OK I skipped over next week being FESCO