From Fedora Project Wiki

(Redirected from Packaging:IRCLog20060727)

(08:30:58) The topic for #fedora-packaging is: Channel for Fedora packaging related discussion | Next Meeting: Thursday, July 20th, 2006 16:00 UTC
(08:36:38) abadger1999: Ayone know what things from the schedule we're hoping to discuss today?
(08:37:30) tibbs: Let's see....
(08:37:38) tibbs: PHP's not done.
(08:37:50) tibbs: Kernel module stuff isn't ready for any kind of vote as far as I can tell.
(08:38:14) tibbs: We haven't talked about compat stuff.
(08:38:34) tibbs: Maybe jpackage naming and a vote on arch-specific noarch stuff.
(08:39:38) tibbs: So far on the list everyone seems to want to flame but nothing constructive is getting done.
(08:42:44) ***f13 tries to prod fnasser into giving some input on jpackage
(08:45:41) f13: hrm, -ENOTIME
(08:46:13) f13: we'll have to table the jpackage naming.
(08:50:43) scop [n=scop]  entered the room.
(08:52:26) rdieter: abadger1999: all/most of the "ratify" items hopefully...
(08:53:17) rdieter: I see the "ScriptletSnippets" topic in the unowned section, I'd propose we ratify/official-ize that too.
(08:53:52) f13: nod
(08:53:53) spot [n=spot]  entered the room.
(08:53:57) abadger1999: The ratify items should just need spot/f13 to say "Core/FESCo signed off" or "Core FESCo had the following issues"
(08:54:02) f13: I haven't seen any problems with them yet, we should just accept them and lock them off
(08:54:36) rdieter: oh, ratify means we're done with those topics then?  yay.
(08:54:38) f13: abadger1999: well, I consider snippits to be a Draft/ still, we haven't as a packaging committee said "we like this, we want to use this, does the constituants agree?"
(08:55:01) spot: hi all, sorry i'm a little late.
(08:55:12) spot: ralf emailed me and said he wasn't likely to be here
(08:56:01) abadger1999: f13: Snippets, yes.  Definitely still a Draft.  Or are you talking about the ratify items?
(08:56:26) f13: no, I was talking about snippets.
(08:56:37) f13: spot: late?  You've still got 3 minutes!
(08:56:53) spot: f13: hm. my internal clock is all screwed up
(08:56:57) spot: stupid west coast.
(08:57:13) f13: yeah, stupid west coast.
(08:57:15) ***f13 sheds a tear
(08:57:18) rdieter: We should make the Snippets official, imo.  What else needs doing?
(08:58:18) spot: are we starting the meeting?
(08:58:25) rdieter: sure.
(08:58:50) tibbs: I'm happy to start.
(08:58:52) abadger1999: Do we have enough people?
(08:58:52) spot: i count 6 people here
(08:59:06) tibbs: It's going to be tough to pass anything.
(08:59:20) rdieter: let's see if we can get more done this week (and try to leave most of the discussion/arguing for the mailing lists instead)
(08:59:21) abadger1999: Consensus! :-D
(08:59:55) spot: apologies in advance, due to OSCON i haven't read much email, almost nothing on f-p-l
(08:59:55) rdieter: maybe we should wait another minute or 2 to see if more show...
(09:01:43) abadger1999: rdieter: I have seen no problem with ScriptletSnippets thus far.
(09:02:14) tibbs: There's still a bit of "to be done" at the end.
(09:02:42) tibbs: And the question of gtk-icon-cache is still undecided, isn't it?  (Although that shouldn't stop ratification of the document.)
(09:03:06) f13: we should adopt it so that it gets used during package reviews
(09:03:09) abadger1999: tibbs: Do you recall what is still outstanding about gtk-icon-cache?
(09:03:19) f13: right now its sort of a floating page that can be overlooked because its not official policy
(09:03:38) tibbs: I think there's an open bug about making it a cron job or somesuch.
(09:04:09) rdieter: The maintainer punted, until recently... and now it's too late to add because fc6 if frozen... grr..
(09:04:14) spot: i think the page looks good as is, even with the minor todos at the bottom
(09:04:40) spot: running gtk-icon-cache is never going to be harmful, worst case, it eats up a minor amt of resources
(09:04:50) tibbs: What's with all of the "(needs description)" bits?
(09:04:50) rdieter: so as it is, gtk-update-icon-cache is still required.
(09:04:58) tibbs: What kind of description is needed?
(09:04:59) abadger1999: Is the problem that gtk2 can be installed after packages providing icons and then the cache is never generated?
(09:05:08) rdieter: no.
(09:05:16) abadger1999: tibbs: Those entries have the scriptlet but no explanation of why.
(09:05:59) rdieter: I take it back, maybe so, but that's gtk2's problem (bug).  I'll add that as a comment to my existing "make it a cron" bug.
(09:06:12) abadger1999: rdieter: I'm on the cron job bug.  I just need to identify how it causes a problem for the scriptlet.
(09:06:54) rdieter: If the bug was fixed, we wouldn't need to mess with it *at all* in pkgs, but as it is, we need both the Requires(post,postun) and the scriptlet.
(09:07:40) abadger1999: rdieter: conary *grin*
(09:08:16) thimm [n=thimm]  entered the room.
(09:08:25) rdieter: yay, one more!
(09:08:33) thimm: Hi, sorry for being late!
(09:08:41) spot: no problem.
(09:08:55) spot: ok, i don't have a lot of time today (i have to go back and work in the booth at OSCON)
(09:08:59) rdieter: Anyone else have issues with the scriptlets, is it worth voting on?
(09:09:16) rdieter: spot: how long?
(09:09:21) scop: voting on exactly what?
(09:09:25) spot: maybe 15 minutes, 20?
(09:09:32) abadger1999: We could vote on whether to make Scriptlets guidelines, taking out all the TODO items, and simultaneously put it in Drafts for enhancement and filling unfinished sections.
(09:09:54) spot: +1 to all of that
(09:09:57) scop: +1
(09:10:00) rdieter: +1, exactly.
(09:10:01) abadger1999: +1
(09:10:10) tibbs: +1.
(09:10:16) f13: +1
(09:10:18) tibbs: Though we should try to fill in the needs description bits.
(09:10:38) spot: ok, it passes. does anyone have anything that they'd like to bring up?
(09:11:00) thimm: Well, kmdls, but 15 minutes are not enough probably
(09:11:10) scop: it's plenty ;)
(09:11:14) tibbs: Nothing on jpackage naming, right?
(09:11:37) rdieter: Where are we on the php business?
(09:11:49) spot: lets talk about php for a minute
(09:11:50) rdieter: Last I heard, jpackage is tabled till next time.
(09:11:52) f13: yeah
(09:12:00) f13: jpackage guys will get back to me later this afternoon
(09:12:06) tibbs: PHP is still a big not done.
(09:12:14) tibbs: f13: We should vote on-list about jpackage, then.
(09:12:29) f13: fnasser has some questions but still hasn't said he hates the proposal.  The other Java guys at Red Hat like it and just want SOMETHING to be accepted.
(09:12:30) tibbs: The deadline is rapidly approaching.
(09:12:49) spot: ok, so what is missing from the php draft right now?
(09:12:51) f13: tibbs: the funny thing is that we don't have to "vote" on anything.
(09:13:09) f13: tibbs: the guidelines don't change at all.  Java packagers just need to follow their formula.
(09:13:30) tibbs: spot: scop and Chris Stone are still arguing over specfile templates.
(09:13:39) abadger1999: f13: as long as they're clear that snapshots have to follow our naming and not jpackage's
(09:13:50) scop: I'm no longer arguing with anyone
(09:14:00) abadger1999: Yeah -- I think I took over.
(09:14:02) tibbs: Plus Remi Collet brought up some stuff about PECL that is over my head.
(09:14:03) rdieter: tibbs: yeah, big deal, whether an empty %build is needed or not (it is, no harm).
(09:14:10) tibbs: s/arguing over/discussing/
(09:14:19) abadger1999: (arguing that is)  Bleagh.
(09:14:21) spot: specifically, is there anything missing on ?
(09:14:27) spot: or is anything undecided there?
(09:15:26) tibbs: What's missing is finalization of some of the macros PECL modules need.
(09:15:26) spot: the only missing item on that page that i see is a ??? where the PECL scriptlets would go
(09:16:06) tibbs: But a bunch of it is probably incorrect if scop's template goes in, because then we have no need of the special PHP macros that live in the not-yet-released php-pear update.
(09:16:38) tibbs: I don't think there's anything blatantly useless or incorrect in the draft, though.
(09:16:57) rdieter: tibbs: afaict, +1
(09:17:12) spot: so, perhaps we should approve the PHP document as it is (remove the ??? section under PECL scriptlets)
(09:17:19) rdieter: agreed.
(09:17:21) spot: we can always revise it later
(09:17:54) spot: +1 to that from me
(09:17:55) rdieter: i approve: +1
(09:18:01) scop: one thing that needs to change: Requires(...) on /usr/bin/pear, but use of %{__pear} in scriptlets
(09:18:02) tibbs: I'm fine with that.  If we do so, I will try to push through a couple of reviews and see what issues show up, and then report back to the list.
(09:18:42) tibbs: scop: so /usr/bin/pear everywhere?  Or %{__pear} everywhere?
(09:18:47) spot: scop: yeah, that should be Requires(...): %{__pear}, right?
(09:19:11) scop: yes, but read my message on f-p-l what problems does it cause
(09:19:42) tibbs: Crap, too many messages.  I'll have to find it.
(09:19:47) scop: that message contained several different approaches to fixing it, too
(09:19:51) ***scop looks
(09:20:13) scop:
(09:20:14) tibbs: <1153851298.2769.396.camel@localhost.localdomain> ?
(09:20:35) spot: IMHO, simple binary macros like that are pointless
(09:20:52) spot: is pear ever going to not live in the FHS approved space
(09:21:02) tibbs: I have no problem with that line of reasoning.
(09:21:06) spot: it's either going to be in /usr/bin or symlinked there
(09:21:22) tibbs: I dislike needless macros because they make my wrists hurt.
(09:21:37) rdieter: Yeah, I'd say go with %_bindir/pear for now (at least until something better comes along)
(09:21:41) spot: so, i say we just get rid of %{__pear} in that document (and the template)
(09:21:54) tibbs: I'm happy to do that now.
(09:22:22) spot: so, lets vote to approve the document with the pear change and the ??? scriptlet section removed from PECL
(09:22:42) tibbs: If we do that, can we push Joe to release the php-pear update soonish?
(09:23:02) tibbs: Otherwise we can't even target FC5 with the stuff in that document.
(09:23:04) spot: tibbs: we can try, but FC is sortof slushy frozen right now
(09:23:32) rdieter: we can do our part, at least, +1
(09:23:58) spot: +1
(09:24:02) tibbs: Yes, +1 and I'll keep the list updated with issues.
(09:24:07) abadger1999: +1
(09:24:13) f13: +1
(09:24:39) thimm: 0
(09:24:55) scop: I would really like to know whether/when the macros will enter FC5
(09:25:36) spot: its somewhat of a chicken-egg issue. we hold the guidelines for the macros, but we want to be sure the macros in the guidelines are right...
(09:25:37) abadger1999: scop: Does your way give us the ability to do it without macros?
(09:25:49) rdieter: scop: It appears to be only a matter of when, and that'll hopefully happen sooner if these guidelines are ratified. (:
(09:25:50) tibbs: scop: Would you work with me to add info on targeting releases without the macros?
(09:25:56) scop: yes, and conditionally defining them in specfiles will work too
(09:26:42) scop: I'm not really comfortable with this, but I'm even less comfortable with standing in the way, so whattahell, +1
(09:27:05) spot: ok, PHP guidelines pass, but we still have to wait a week for FESCO
(09:27:19) thimm: Or an hour?
(09:27:20) spot: so the hold on php packages won't lift for a week
(09:27:50) scop: tibbs, what do you mean by "add info on targeting"?
(09:28:02) spot: well. i suppose it could take effect immediately if FESCO doesn't have a problem.
(09:28:05) abadger1999: thimm: It has to be bounced off Core concerns as well.  Don't know that it has to wait a whole week, though.
(09:28:22) ***spot has to go now
(09:28:29) rdieter: spot: have fun.
(09:28:45) spot: who wants to take this item to FESCO (since i'm going to miss it outright)?
(09:28:50) tibbs: scop: Add info on how to make packages that work on FC4, probably by including conditional definitions of the needed macros.
(09:29:02) tibbs: spot: I'll run it by FESCo.
(09:29:06) spot: tibbs: thanks
(09:29:18) rdieter: Is it worth trying to get more done if we're spot-less? (sorry, had to say it)
(09:29:41) scop: tibbs, no thanks, I have no personal interest in PHP and I've been flamed enough while trying to help anyway
(09:30:26) tibbs: scop: I have no personal interest in PHP either.  Funny, isn't it?
(09:30:28) thimm: rdieter: w/o spot we are only 6, so anything that needs decided would need 100% +1 :)
(09:30:50) rdieter: ok then, kernel modules?  (:
(09:30:50) tibbs: We probably couldn't agree on ending the meeting.
(09:31:02) thimm: How about BuildRoots?
(09:31:13) rdieter: I'm game for buildroots.
(09:31:18) tibbs: Is there one all-singing, all-dancing buildroot?
(09:31:20) f13: the interested parties regarding buildroots aren't here.
(09:31:26) tibbs: Not really fair to discuss it without Ralf.
(09:31:32) f13: nor Axel
(09:31:42) tibbs: thimm is here.
(09:31:49) rdieter: I think we all know how Ralf feels about that already, don't we? (:
(09:31:50) f13: oh I'm blind.
(09:32:11) f13: I think this needs a bit more discussion.
(09:32:44) f13: so far we can't even agree on what is a 'broken' buildroot
(09:32:50) tibbs: I would like to see a page with all of the proposals and arguments summarized.
(09:32:56) f13: nod
(09:33:06) thimm: OK, I'll create a page
(09:33:08) rdieter: ok, that's a veto, any other topics?  how about "Files Generated by Scriptlets"?
(09:33:15) abadger1999: tibbs, scop: macroless PHP stuff should all be in the spec template bug, though, right?
(09:33:38) tibbs: abadger1999: Yes, it is, although it's in a series of patches.  I'm not sure which apply to what at this point.
(09:34:06) tibbs: scop: Any chance at all you could just mail the macro-less template to me?
(09:34:08) thimm: f13: does disttags for legacy RH7.3/9 make sense anymore? Probably not, or?
(09:34:17) scop: the initial "food for thought" patch should still apply over current rpmdevtools CVS
(09:34:18) f13: no
(09:34:21) scop: tibbs, sure
(09:34:41) f13: thimm: our build system won't support it, and I'm not interested in making any changes to that since its going bye bye
(09:34:58) tibbs: f13: Did we ever cover disttags for RHEL?
(09:35:08) f13: yes, .el#
(09:35:38) tibbs: OK, good.  Now the only open issue with that is dist tags for rawhide.
(09:35:50) tibbs: which I recall was a can of worms.
(09:36:02) f13: rdieter: files generated by scriptlets should be cleaned up by scriptlets too.
(09:36:16) rdieter: right, hopefully, we can all agree on that?
(09:36:26) f13: rdieter: but I think files generated by scriptlets are ugly, since they aren't going to be listed in rpm -ql or rpm -V
(09:36:29) abadger1999: What about %ghosted?
(09:36:38) rdieter: Furthermore, the generated files whould be owned (via %ghost)
(09:36:38) thimm: tibbs: The ideal time to discuss this will be after the mass rebuild but before fc6 release
(09:36:41) f13: abadger1999: that _could_ work.
(09:36:56) rdieter: whould ->should
(09:37:00) thimm: rdieter: generated files like certificates?
(09:37:11) rdieter: thimm: that's one example, yes.
(09:37:19) thimm: Do we really wnat to remove them?
(09:37:22) tibbs: thimm: You're right, but that is approaching and it would be good to see the proposal written down with the arguments listed out.
(09:37:56) rdieter: thimm: auto-generated certs?  Yes, why not?
(09:38:03) thimm: generated certificates: Suppose user upgrades dovecot with rpm -e /rpm -U
(09:38:12) thimm: He loses the certificates
(09:38:16) rdieter: so?
(09:38:46) thimm: Distributing certificates can be a PITA
(09:38:52) rdieter: Oh, you mean get overwritten?
(09:39:05) thimm: Yes, erased and then recreated
(09:39:25) rdieter: Then don't do that! (: (only upgrade)
(09:40:33) thimm: BTW %ghost: Doesn't that automatically remove the files?
(09:40:45) scop: no, if the file existed beforehand
(09:41:00) thimm: how does rpm know?
(09:41:07) scop: beats me :)
(09:41:21) rdieter: A proposal pertaining to that topic is also at
(09:41:38) thimm: I thought %ghost means: "don't package it. but otherwise assume it's our file."
(09:41:55) thimm: And %ghost is used for getting pyo removed
(09:42:16) thimm: So probably %ghosting generated files is already enough
(09:42:23) rdieter: afaik, %ghost removes files on erase, yes, but won't overwrite an existing file on install.
(09:42:49) scop: rdieter, and when I last tested, it did not remove %ghosted files if they were present before installing the package
(09:43:06) rdieter: scop: interesting.  that's lame then.
(09:43:27) thimm: Maybe a bug in %ghost implementation?
(09:43:34) rdieter: at least the file is *owned* though... (:
(09:43:36) thimm: I never found any authoritative info on them
(09:43:38) scop: or maybe a feature?  hard to tell
(09:43:54) thimm: Well, most rpm bugs are cast into features :=)
(09:44:16) ***scop giggles
(09:44:21) thimm: Like the Provides:-implies-Obsoletes:-but-only-if-it-s-not-virtual
(09:44:24) rdieter: Either way, it is worth voting on?
(09:44:38) thimm: How about passing the ball back to the packager?
(09:44:53) thimm: "Every generated file needs to be removed after the package's removal"
(09:44:58) thimm: We don#t care how
(09:45:24) rdieter: I'd rather "Every generated file should be owned" (which implies removal, but maybe not ?)
(09:45:44) thimm: Then have both in the wording "owned and removed"
(09:45:44) scop: think %ghost %config
(09:45:55) rdieter: thimm: +1 exactly.
(09:47:16) rdieter: So we'll go with "Every generated file should be owned (via %ghost) and steps be taken to ensure their removal on package uninstall"?
(09:47:39) scop: should or must?
(09:47:41) spot left the room (quit: Read error: 110 (Connection timed out)).
(09:47:41) abadger1999: Wait, did we decide it's okay to remove certificates?
(09:47:54) scop: either way, 0 - need to think about it more
(09:48:04) rdieter: That's the packager's call, either they mark it %config or not.
(09:48:10) tibbs: I personally wish we wouldn't, but I keep backups for that kind of thing.
(09:48:17) rdieter: %config, keep, not %config removed.
(09:48:42) tibbs: In any case, most of us who care will be generating our own certificates and not using ramdomly-installed ones.
(09:48:46) scop: what if the file is not %config, but keeping would still be preferred?
(09:48:50) tibbs: Which does imply %config.
(09:49:10) scop: what exactly is in the scope of "every generated file"?
(09:49:12) rdieter: tibbs, scop: bug the packager to mark it %config? (:
(09:49:19) thimm: What other types of files other than certificates are usually generated?
(09:49:26) rdieter: scop: scope is in scriptlets.
(09:49:46) tibbs: thimm: ssh keys (but that's really just another cert).
(09:49:59) slack_: databases
(09:50:09) scop: slack_, in scriptlets?
(09:50:14) tibbs: Also config files that need a random password.
(09:50:15) thimm: We shouldn't nuke mysql/ldap data
(09:50:38) rdieter: thimm: if you don't want mysql data nuked, don't uninstall the pkg.
(09:50:45) slack_: scop: ah, true...
(09:51:00) scop: rdieter, seriously?
(09:51:19) thimm: suppose soemone wants to use the mysql packages from the vendor
(09:51:24) rdieter: scop: kinda (not 100%). (:
(09:51:32) thimm: And he rpm -e fedorapackage, rpm -Uhv mysqlpackage
(09:51:39) rdieter: thimm: then burn them at the stake. (:
(09:51:43) tibbs: I don't think a mysql database has any business being owned by the mysql package.
(09:51:58) scop: me neither
(09:52:02) tibbs: If I uninstall sendmail, it doesn't delete /var/spool/mail.
(09:52:08) thimm: :)
(09:52:16) f13: no, it shouldn't be owned.
(09:52:18) thimm: It does so while running ;)
(09:52:32) rdieter: tibbs: mysql doesn't own it, package foo creating it does.
(09:52:42) thimm: OK, so the generated files are usually passwords and certificates
(09:52:45) abadger1999: postgresql packages often get uninstalled when someone forgets to dump their database before an incompatible upgrade.
(09:52:54) thimm: In general authentication bits
(09:52:57) f13: and really, if we need a DB generated, it should be done the first time the service is started, not in %post
(09:53:06) f13: (like how openssh generates its keys)
(09:53:18) scop: and like the db's do...
(09:53:26) thimm: I still feel uncomfortable with packages removing say ssh keys
(09:53:51) rdieter: ok, definitely need to think about this a bit more.
(09:54:01) f13: what package is creating ssh keys in %post ?
(09:54:08) thimm: openssh
(09:54:16) scop: thimm, really?
(09:54:28) mmcgrath: mod_ssl might too
(09:54:30) tibbs: Sorry, I was mistaken when I said openssh did that.
(09:54:32) rdieter: I thought openssh generated the keys when the service was starte for the first time.
(09:54:39) tibbs: It's the init file that creates the SSH keys.
(09:54:42) thimm: Yes, sorry
(09:54:51) thimm: But it's the same, isn't it?
(09:54:58) rdieter: But many packages do make ssl certs in %post.
(09:54:59) tibbs: Perhaps we could indicate that it's preferred that keys for daemons be created at runtime?
(09:55:00) thimm: Whether it's %post or the run time script
(09:55:22) abadger1999: Yes, mod_ssl does.
(09:55:23) rdieter: tibbs: do we really care whether it's %post or at runtime?
(09:55:46) f13: well, if we want the package to cleanup everything it creates, then it should be at runtime
(09:55:46) thimm: dovecot also generates at install time
(09:55:57) thimm: f13: why?
(09:56:04) f13: because think about places that do an install to a disk image, then deploy that image across many systems.
(09:56:11) f13: we want that key to be unique and generated at run time, not install time.
(09:56:21) thimm: Correct!
(09:56:22) rdieter: f13: ok, I see that.
(09:56:43) thimm: That's maybe a guidline of it's own
(09:56:51) tibbs: This feels like a beer commercial.  Man law?
(09:56:53) rdieter: maybe we could add that suggestion to
(09:57:30) abadger1999: But with a note in the owning/removing section that points to dealing with certificates.
(09:57:48) thimm: There are arguments about generating certificates not at run-time, but I think f13's arguments outweighs them
(09:58:06) thimm: dovecot for instance moved it to the %post because it took too long
(09:58:19) tibbs: thimm: That seems backwards.
(09:58:31) tibbs: I'd move it to runtime if it takes too long.
(09:58:35) scop: ditto
(09:58:55) tibbs: Imagine the hypothetical everything install.
(09:59:00) thimm: I agree, I just quoted why dovecot did so
(09:59:24) rdieter: ok, time for FESCo...
(10:00:23) abadger1999: I copied the ScriptletSnippets page under Drafts minus the TODO items.
(10:00:53) abadger1999: When that's ratified I'll move the current SriptletSnippets to Drafts so people can continue working on the TODO items.
(10:02:23) f13: cool
(10:12:47) thimm: ttfn