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