Meeting:Packaging IRC log 20061212

Fedora Packaging Meeting of 2006-12-12; times are in America/Los_Angeles

(08:40:51 AM) ***f13 won't be at meeting
(08:40:55 AM) f13: neither will spot
(08:43:06 AM) tibbs: I think Axel's away as well.
(08:57:55 AM) thimm [n=thimm@p54BD7244.dip.t-dialin.net]  entered the room.
(09:00:00 AM) racor [n=rc040203@Taea6.t.pppool.de]  entered the room.
(09:01:04 AM) devrimgunduz [n=Devrim@evim.gunduz.org]  entered the room.
(09:02:00 AM) tibbs: So, who's around?
(09:02:13 AM) ***thimm is
(09:02:24 AM) racor: me
(09:02:31 AM) lutter: I am here
(09:02:57 AM) ixs: mhm. I've got nothing to contribute anyway. ;D
(09:03:43 AM) scop [n=scop@cs27014175.pp.htv.fi]  entered the room.
(09:04:07 AM) tibbs: rdieter: around?
(09:04:51 AM) tibbs: Well, scop makes five.  Perhaps Rex will return as well.
(09:05:00 AM) rdieter: I'm about 75% here. (:
(09:05:12 AM) rdieter: flaky net connection, so cross your fingers.
(09:05:47 AM) rdieter: topics?
(09:06:11 AM) tibbs: And we know abadger*, f13 and spot are away, so that's the best we're going to get.
(09:06:29 AM) tibbs: Yeah, mine is bad as well.  Work blocks IRC so I have to tunnel through my home machine.
(09:07:39 AM) rdieter: can we hit icon_cache?  I'd like to get some movement there.
(09:08:25 AM) rdieter left the room (quit: Remote closed the connection).
(09:09:09 AM) tibbs: There was good discussion about Spot's draft on the list, but it looked to me like a few changes were needed and the current draft doesn't reflect that.
(09:09:21 AM) tibbs: Crap, my connection is getting really flaky now.
(09:10:28 AM) rdieter [n=rdieter@sting.unl.edu]  entered the room.
(09:10:45 AM) tibbs: Maybe something will get through...
(09:10:45 AM) tibbs: About the icon cache stuff, I'm concerned that we'll just have to redo it all once the proper packages get in.
(09:11:14 AM) tibbs: rdieter: You may have missed my earlier comment; it's hard to tell what's actually getting out through this crappy connection.
(09:11:21 AM) tibbs: It was:
(09:11:54 AM) scop: tibbs++, IMO icon cache stuff is better postponed to until when xdg-utils is ubiquitous
(09:12:30 AM) rdieter: I'm back.
(09:12:41 AM) scop: there was an on-list request for user creation clarifications - I can extend my "handling users/groups on uninstall" item to that unless there are objections
(09:13:15 AM) rdieter: scop: do it.
(09:13:29 AM) tibbs: About the icon cache stuff, I'm concerned that we'll just have to redo it all once the proper packages get in.
(09:13:49 AM) rdieter: tibbs: right, it'll be a 2-step process.
(09:14:18 AM) rdieter: tibbs: fix the ugliness as it is *now*, then switch to xdg-utils for fc7+
(09:15:16 AM) rdieter: maybe we don't agree that the current situation basically sucks rocks.
(09:15:50 AM) rdieter: I've been going on the assumption that is a given.
(09:15:50 AM) lutter: rdieter: what happens now ?
(09:16:13 AM) scop: I think icon cache stuff could be a candidate for macroization in redhat-rpm-config
(09:16:15 AM) rdieter: we're forcing 100's of packagers to workaround a gtk2 bug.  I say stop it, stop itnow.
(09:16:47 AM) rdieter: lutter: force the issue, stop the workaround, lean on gtk2 matinainer to step up and do the right thing.
(09:16:57 AM) racor: rdieter: how ? force xdb-utils NOW?
(09:17:13 AM) rdieter: no, drop mandatory usage of gtk-update-icon-cache in scriptlets.
(09:17:34 AM) scop: without promises from the gtk2 maintainer it would basically be a shift from punishing packagers to punishing GNOME users, no?
(09:17:37 AM) rdieter: keep (only) the 'touch' bit (for now), and do xdg-utils for fc7+
(09:17:40 AM) tibbs: I don't think we should be forcing issues like that.
(09:18:05 AM) rdieter: scop: yes, if need be, but I'd even be wililng to give gtk2 maintainer a deadline to fix it.
(09:18:45 AM) rdieter: tibbs: you think it acceptable for us making packaging policies to simply workaround known/fixable bugs?
(09:18:58 AM) rdieter: tibbs: I'm concerned if nothing is done, the bug will never get fixed.
(09:20:21 AM) rdieter: if there's no support for this from the rest of the committee, I'll simply drop it, though.
(09:20:26 AM) lutter: I am not very hot on a cron job that updates /usr at essentially random times
(09:20:37 AM) scop: is it clear how the issue should be fixed in gtk2 assuming xdg-utils is not available?
(09:20:57 AM) rdieter: scop; it's clear to me. (:
(09:21:16 AM) scop: cron job does not sound like a right thing to do to me
(09:21:33 AM) rdieter: imo, cron job is preferable to the status-quo.
(09:21:57 AM) rdieter: either way, it's not *our* probloem, it's gtk2's problem.
(09:22:09 AM) tibbs: Our job is to develop guidelines for producing functional packages.  There's brokenness everywhere, but fixing that is not our mandate.
(09:23:19 AM) rdieter: agreed.  So why are we (with the status quo)?  I'm arguing exactly that, we produce functional packages that just work, nothing more.
(09:24:01 AM) rdieter: gtk-update-icon-cache is not *required* for functional packages.
(09:24:38 AM) rdieter: I just don't get it, why folks are defending it's use.
(09:25:24 AM) scop: personally, I don't find a oneliner that doesn't add any dependencies that intrusive
(09:25:49 AM) rdieter: a one liner in 100's packages, is intrusive.
(09:26:13 AM) rdieter: I don't mind folks using it *if they want to*, I just object to making it *mandatory*
(09:26:16 AM) lutter: but it triggers the update at exactly the right time, w/o the need for demons, cron jobs etc.
(09:26:30 AM) rdieter: *sigh*.
(09:26:50 AM) scop: is it mandatory?
(09:27:03 AM) lutter: it would be nicer if we had a rpath-like tagging system so that the packager could just say 'this package has an icon theme' and rpm macros do the necessary magic, but that's a little pie-in-the-sky
(09:27:12 AM) rdieter: scop: it's in the Packaging Scriptlets, people consider it's use mandatory, even though it *should not be*
(09:27:38 AM) rdieter: lutter: sure, in handy-wavy-future land, but we're talking about *right now*, thank you. (:
(09:28:55 AM) rdieter: like I said, if there's no support for this, I'll drop it  We can talk about something else.
(09:29:11 AM) lutter: rdieter: it wouldn't be hard to write a rpm macro for that .. the hard bit is getting it into everybody's /etc/rpm
(09:29:11 AM) scop: well, I think people should be encouraged to understand what ScriptletSnippets is
(09:29:38 AM) rdieter: scop: of course, that is (should be!) a given.
(09:30:02 AM) rdieter: that was part of my proposal, adding links to the fdo icon spec describing its intent and usage.
(09:30:27 AM) lutter: rdieter: what are the chances of getting xdg-utils on every Fedora installation ?
(09:30:59 AM) rdieter: lutter: for fc7, (near) 100%.  we can't really do that for earlier releases.
(09:31:13 AM) racor: rdieter: why?
(09:31:48 AM) lutter: that means that spec files need to be forked :(
(09:31:51 AM) rdieter: well, we could add Requires(post,postun): xdg-utils for packages using it, I supopse, but I'd rather avoid that.
(09:32:57 AM) racor: rdieter: that's what I had in mind
(09:33:04 AM) lutter: I'd be all for that as an option together with the last snippet on your proposal
(09:33:17 AM) racor: recommend them, then they'll creep in automatically
(09:33:20 AM) rdieter: lutter: with auto icon cache rebuilding, no forkage is required (and we could stick with 'touch' approach).
(09:34:25 AM) rdieter: OK, I'll update the proposal for an option for Requires(post): xdg-utils
(09:35:13 AM) rdieter: I'd rather it be KISS and have only 1 option, but maybe that's not reasonably possible
(09:35:17 AM) lutter: rdieter: yeah, but it's much harder and much more invasive than making people add a little cruft to their specfiles .. I'd prefer the cruft is minimal, but I don't want like to have all kinds of stuff watching for cahnges if there's an easy way to know when a change is needed
(09:35:57 AM) rdieter: fair enough, I'm willing to compromise.
(09:37:20 AM) rdieter: I'll update the proposal, then I can hash it over some more... .any other topics?
(09:37:21 AM) scop: I'd like to add a bit of rationale to the "|| :" in the texinfo scriptlet snippet
(09:37:47 AM) scop: been playing around with %_excludedocs 1 installs... :P
(09:38:08 AM) rdieter: scop; you could probably add a rationale for it's general usage for any/most scriptlets.
(09:38:29 AM) scop: there's a tip at the bottom of the page already
(09:38:38 AM) rdieter: assuming you mean: scriptlet failures are bad, mm-kay?
(09:38:44 AM) scop: yeah
(09:39:13 AM) rdieter: what kind of clarification did you have in mind?
(09:39:47 AM) scop: actually it's mostly covered by the blurb at the bottom
(09:40:05 AM) rdieter: so, no change?
(09:40:23 AM) scop: bump it somewhere more prominent, at the top of the page?
(09:40:53 AM) lutter: sure .. is '|| :' really controversial ?
(09:40:55 AM) rdieter: or maybe make it a footnote, referenced whenever it's used in the sciprtlets?
(09:41:14 AM) rdieter: lutter: shouldn't be controversial, it's generally a good idea.
(09:41:35 AM) thim2 [n=thimm@p54BD7EC6.dip.t-dialin.net]  entered the room.
(09:41:38 AM) lutter: I like scop's idea of having a little 'some general things about shell scripting and rpm' section at the top
(09:41:52 AM) scop: I don't think it's controversial, but I was just astonished by the amount of Core packages not doing it
(09:42:04 AM) racor: lutter: yes, the ||: makes sense for texis (due to %doc), but outside of %docs it's almost always wrong
(09:42:57 AM) scop: at the very least, anything that handles %docs or tries to write to /usr/share in scriptlets needs the "|| :" or other graceful failure ways
(09:43:01 AM) rdieter: racor: it's safer to have ||: in case of scriptlet errors/typos that would otherwise abort a pkg upgrade.
(09:43:59 AM) racor: rdieter: It's better to be confronted with bugs during testing, than to let ||: cause package slip through QA
(09:44:22 AM) rdieter: racor: sure, borked rpm-db is ok, not.
(09:44:39 AM) racor: see, it's controversial ;)
(09:44:52 AM) lutter: lol
(09:44:56 AM) scop: how about taking it to an extreme, and lobbying %post and friends to have a 0 exit status by default?
(09:45:10 AM) lutter: so it really needs to be moved to a more prominent location in the writeup
(09:45:15 AM) rdieter: scop: not unreasonable.
(09:45:31 AM) lutter: scop: +1
(09:45:49 AM) rdieter: scop: writeup a proposal, and we can discuss/vote on it.
(09:45:53 AM) thimm left the room (quit: Read error: 60 (Operation timed out)).
(09:46:18 AM) scop: I'll add it to my list, even though I'm not quite convinced it'd be a good idea myself yet ;)
(09:46:20 AM) lutter: scop: ideally we would have macros that do the right thing instead of forcing ppl to cut&paste snippets into each rpm
(09:46:51 AM) rdieter: lutter: step 1: agree what the scriptlets should be, then we can macro-ize them. (:
(09:47:07 AM) lutter: rdieter: you're right
(09:47:43 AM) rdieter: I'm foggy, the rpm scriptlet macros only need be available at *build* time, right?
(09:48:04 AM) rdieter: if so, it's easily do-able.
(09:48:04 AM) scop: yes
(09:48:22 AM) scop: all macros expand at build time
(09:48:44 AM) rdieter: downside would be that our (Feodra) packages would be less portable, but that's not our problem, wight?
(09:48:53 AM) rdieter: s/wight/right/
(09:49:02 AM) rdieter: (:
(09:49:13 AM) scop: depends
(09:49:37 AM) scop: less portable between eg. Fedora and RHEL would be an annoyance
(09:49:55 AM) racor: well, did anybody of you use SuSE? Their specs are cluttered with macros, making them a real annoyance
(09:50:13 AM) scop: Mandriva uses lots of them as well
(09:50:18 AM) racor: one lesson, I learnt from this: Avoid them whenever possible
(09:50:19 AM) rdieter: scop: even RHEL(EPEL) would/should be fine.
(09:50:30 AM) scop: (just observing specfiles, haven't really used Mandriva/SuSE)
(09:50:59 AM) scop: rdieter, not sure I understand?
(09:51:22 AM) rdieter: scop: distros where we control the buildsys shouldn't be a problem. (:
(09:51:30 AM) lutter: scop: tehre's already subtle differences between FE and RHEL (e.g. in the assumption what's ina  buildroot)
(09:52:01 AM) scop: the macros need to be user installable too
(09:52:11 AM) scop: and available in the distros
(09:52:25 AM) lutter: absolutely .. and a BR: magic-rpm-macros
(09:52:34 AM) scop: lutter, not sure about that
(09:53:00 AM) scop: we already now rely on behaviour injected by redhat-rpm-macros
(09:53:08 AM) thim2: BR on macros does not work
(09:53:12 AM) scop: yet no packages have a BR on it
(09:53:38 AM) racor: scop: yes - a major pain - They are helpful and harmful to the same extend
(09:53:44 AM) lutter: thim2: depends on when you use hte macros ;)
(09:53:54 AM) racor: scop: the buildsys has
(09:54:03 AM) thim2: It breaks already at rpmbuild -bs
(09:54:13 AM) scop: thim2, not necessarily'
(09:54:18 AM) scop: it depends
(09:54:27 AM) thim2: If unknown macros are used it will
(09:54:47 AM) scop: no it won't, if they're used in parts of the specfile which is not evaluated at build time
(09:54:55 AM) scop: s/build time/-bs time/
(09:55:10 AM) thim2: All of the sepcfile goes through the parser, or not?
(09:56:01 AM) scop: well, just try adding a %post with contents %fubarquuxwhateva and watch it -bs just fine...
(09:57:09 AM) rdieter: especially if you use something safe like %{?fubarquadflkajf}
(09:57:33 AM) scop: whether that's any safer depends again on the case
(09:57:55 AM) thim2: Indeed, scoop, you're right
(09:58:02 AM) thim2: It doesn't kill rpmbuild
(09:58:13 AM) thim2: Sorry, s/scoop/scop/
(09:58:42 AM) thim2: So BR and macros in %scripts are safe, good to know!
(09:59:46 AM) scop: I believe they're safe for everything that doesn't end up in the SRPM header and doesn't break specfile syntactically
(10:00:00 AM) scop: eg. inside %build, %install, %prep, ...
(10:01:03 AM) scop: anyway, quickly back to the topic, I'll add an AI for moving the "|| :" stuff at the top of scriptletsnippets
(10:02:03 AM) thim2: AI?
(10:04:17 AM) scop: Action Item
(10:06:25 AM) rdieter: anything else?  We're pretty much out of time.
(10:10:31 AM) lutter: seems like that's it
(10:11:53 AM) scop: yep, need to go, thanks