From Fedora Project Wiki

The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.
(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 http://fedoraproject.org/wiki/PackagingDrafts/PHP ?
(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: https://www.redhat.com/archives/fedora-packaging/2006-July/msg00297.html
(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 http://fedoraproject.org/wiki/PackagingDrafts/Certificates
(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 http://fedoraproject.org/wiki/PackagingDrafts/Certificates
(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