Meeting:Packaging IRC log 20060824

(09:00:32) ***f13 idles (09:03:38) lutter: are we having the meeting ? (09:03:50) lutter: (haven't checked email yet) (09:04:50) tibbs: My assistant is on vacation today so my attention will be split. (09:05:00) rdieter: akaik, yes, but no sign of spot (09:06:06) ***scop counts 6... (09:07:34) abadger1999: Six can vote if we all agree :-) (09:09:08) abadger1999: I'll start with a news item. (09:09:10) rdieter: and it'll hardly be any fun without either Ralf or Axel. ;) (09:09:38) abadger1999: The mono directory has moved to %{_libdir} in RawHide. (09:10:19) tibbs: Has any progress been made on any of the "writeup" tasks? (09:10:23) ixs: rdieter: *shush* (09:11:19) abadger1999: tibbs: Yes. Let me move things around there... (09:11:19) scop: I wrote about optflags, but can't update ReviewGuidelines (09:11:22) rdieter: abadger1999: why? maybe my memory is failing me, but I thought we had agreed to stick with /usr/lib? (09:11:54) abadger1999: rdieter: I'd have to look through the meeting logs bug we agreed to put things into %{_libdir} (09:12:11) rdieter: ok, senility then... (09:12:27) abadger1999: With a temporary allowance that things that used gacutils to install into mono's "global assembler cache (GAC)" would continue in /usr/lib (09:12:45) abadger1999: because the mono package controls where the gac is located. (09:12:50) f13: mono is such a disaster :/ (09:13:15) f13: tibbs: I installed the changelog templates to the Guidelines. (09:13:27) abadger1999: So with the rawhide changes, FC6+ all parts of mono can go to %{_libdir} (09:13:36) abadger1999: no more exceptions :-) (09:13:59) tibbs: scop: Why can't you update ReviewGuidelines? (09:14:10) scop: tibbs, Wiki says immutable (09:14:18) tibbs: Ah, for me as well. (09:14:32) tibbs: Spot has that exclusively for himself. (09:14:36) ***f13 grabs his sandwich (09:14:38) tibbs: #acl TomCallaway:read,write All:read (09:15:36) tibbs: scop is the only person here who has an easyfix item on the schedule. (09:16:12) tibbs: but I'm not sure if it would even be worth it to vote. (09:16:25) scop: depends (09:16:51) f13: we could talk a bit about some rpmlint issues... (09:17:05) tibbs: Some of scop's item isn't any of our business. (09:17:43) abadger1999: I think FESCo approved the portion that isn't ours to deal with. scop, do you want to outline the part that's left? (09:17:43) scop: the meat of it is, IMO (Provides/Obsoletes) (09:17:52) scop: yes, that's my task (09:18:12) scop: I think I know what I'd like it to be, but I'm having a hard time formulating it :) (09:19:28) rdieter: +1 to whatever scop says. (: (09:19:38) scop: would "add the Provides only if the new package can be used as a drop-in replacement" be too draconian? (09:20:08) rdieter: I think that wording is reasonable (and factually correct) (09:20:12) tibbs: I guess the important question is what breaks if you obsolete but don't provide. (09:20:33) f13: hrm. (09:20:39) rdieter: tibbs: afaik, nothing breaks (09:20:42) f13: I THINK it would remove the old package, but I'm not sure. (09:20:52) f13: maybe the old package would be left around, and potentially start creating broken deps (09:20:59) scop: yep, and on the other side, what expectations break if you do but the package actually doesn't deliver the old bits (09:21:27) tibbs: The advice has always been to provide what you're obsoleting so that things don't break, but I've never known what breaks. (09:21:28) rdieter: f13: the oldpackage is removed (as well as creating missing dep for any package that Requires: now missing pkg) (09:21:44) f13: scop: I'd be more in favor of 'provides the same functionality'. May not necessarily be a drop in. (09:21:57) rdieter: point is, if the new package really isn't a drop-in replacement, the Provides is bogus/wrong anyway (09:22:06) scop: f13, I think that's too "loose" (09:22:10) f13: rdieter: would it be removed if it would break deps? Wouldn't that halt the yum transaction? (09:22:11) tibbs: I guess the idea is to make sure that people who try to install the old package get the new one, but that causes other problems, which I guess is the point of this discussion. (09:22:38) f13: tibbs: rdieter: ok, I'm fine w/ 'drop-in'. (09:22:42) scop: ok, examples: openmotif -> lesstif (09:22:55) rdieter: f13: not sure what yum would do. I *think* it remove anything depending on the removed pkg as well. (09:23:03) f13: ooh ooh! Maybe we can create yet another rpm tag, SuggestedReplacement: (09:23:18) tibbs: f13 > jbj ? (09:23:27) scop: rdieter, I believe the whole transaction would be aborted (09:23:31) f13: tibbs: yes, tounge in cheek (09:23:58) f13: whatever we decide, the wording of the rpmlint warning would need to be updated. (09:24:00) rdieter: either way is ok (by me), but pkgs with broken deps will need to be fixed/rebuilt regardless. (09:24:25) tibbs: So is it reasonable to leave this up to the packager to decide when obsoletes should be provided and when they shouldn't? (09:24:50) f13: tibbs: isn't that too 'loose' ? (09:25:06) tibbs: I don't think we can define it rogorously. What does "drop in" mean? (09:25:30) tibbs: Obviously package renames are on one end of the spectrum; same functionality, different name. (09:25:38) scop: drop in = no changes to other packages needed, nothing breaks (09:25:40) rdieter: tibbs: the packager/maintainer certainly is the one to make the call, keeping in mind that Provides need to be legit (not bogus/wrong) (09:25:58) tibbs: motif/lesstif is probably the other end of the spectrum: sort of the same thing, but not really. (09:26:10) abadger1999: scop: What about a rebuild? Library is API compatible but not ABI compat. (09:26:20) rdieter: lesstif/openmotif is irrelavent, lessitf doesn't provide same soname. (09:26:30) rdieter: ie, not abi-compatible (09:26:36) scop: abadger1999, dunno (09:26:45) scop: another example: ethereal -> wireshark (09:26:45) Rathann: it's not even feature-compatible (09:26:59) f13: also things like if the new package's options are different (09:27:04) scop: wireshark provides ethereal (unversioned!), but /usr/bin/ethereal no longer exists (09:27:29) rdieter: regardless, Obsoletes/Provides should always be *versioned*. (09:27:32) f13: say if we replace cdrecord w/ something else, it would obsolete cdrecord, but since the options aren't the same (thus the API), it wouldn't necessarily Provide: cdrecord (09:27:38) lutter: it should at least provide asymlink or wrapper script (09:27:46) f13: scop: thats a bug in wireshark. It probably should have a symlink. (09:28:12) scop: right (09:28:22) f13: Obsoletes: foo =< last-shipped (09:28:34) f13: Provides: foo = %{version}-%{release} (09:28:44) lutter: abadger1999: I think abi-incompatibility should be treated exactly how it would if upstream just bumps hte version and breaks abi (09:29:12) f13: hrm. (09:29:27) f13: rdieter: my suggestion only works if the last-shipped foo EVR is lower than the replacement one. (09:30:11) rdieter: f13: sure. Versioning ought to be used if only for the ability to change one's mind later (09:30:16) thimm [n=thimm] entered the room. (09:30:23) thimm: Hi, sorry for being late (09:30:26) scop: anyway, I think we all basically agree, I'll try to come up with some words to describe it (09:30:46) f13: rdieter: so Obsoletes: foo (09:31:01) f13: Provides: foo = %{version}-%{release} (09:31:02) f13: ? (09:31:13) scop: that's self-obsoleting (09:31:30) rdieter: f13: the Obsoletes should be *versioned* always(*) (09:31:38) rdieter: (*) sure, there are exceptions (09:32:14) f13: rdieter: ah. (09:32:30) f13: I sense a Draft coming up (: (09:32:45) rdieter: more like: Obsoletes: foo < last-shipped++, Provides = last-shipped++ (09:32:48) abadger1999: thimm: np. The story so far: http://www.fedoraproject.org/wiki/Packaging/IRCLog20060824 (09:32:50) f13: hi thimm, we havne't voted on anything yet, just doing some discussion. (09:36:30) scop: I'll draft something.  Next item? (09:37:15) tibbs: f13 wanted to talk about some rpmlint things. (09:37:16) thimm: Thanks for uploading the log! (09:38:07) f13: I'm wondering if we really care about mixed tabs/spaces and if we shoudln't just go by 'this looks visually OK' or 'this thing is arranged all to hell' (09:38:36) f13: also there was some disscussion regarding relative symlinks. (09:39:09) tibbs: I haven't been blocking on the spaces/tabs thing. (09:39:43) tibbs: The warning is somewhat bogus in any case; if you use a single tab and a single run of three spaces anywhere in your spec, you get that warning. (09:40:12) f13: nod (09:40:25) f13: I'm wondering if we should add that warning to a fileter file we ship w/ the rpmlint package (09:40:36) scop: the intention of that check is "is there a mixture of spaces and tabs for indentation?" (09:40:45) f13: its not going to get removed in the upstream source, but we can filter it in our package of it. (09:41:19) f13: scop: sure, I understand the intention, I'm just not so sure we should really care about somethign so pendantic (09:41:31) f13: if it looks ok, whatever. If it looks like hell, have the developer fix it. (09:42:09) scop: f13, yep, understood, I said that as a response to tibbs' concern about the implementation (09:42:36) scop: I have no opinion on this, except that I sure as hell do want to be whined if any packages of mine have a single tab ;) (09:42:44) scop: but that's something I can take care of locally (09:44:34) scop: I guess this is somewhat about whether we want to use rpmlint as an exclusive enforcer of guidelines, or as a tool that can additionally emit things outside of them that some people find useful, others possibly not (09:44:36) f13: Proposal: (09:44:58) f13: Filter the tab/space check in the Fedora packages. Use visual ability to determine if the spec needs adjusting. (09:45:02) f13: +1 (09:45:33) tibbs: I don't think it's our business to tell scop what to filter. (09:45:34) rdieter: +1 (09:45:36) abadger1999: scop: I lean towards your second definition. (09:45:42) f13: scop: well, the guidelines say that the package has to pass rpmlint, so that will cause confusion if we say 'it has to pass rpmlint, but ignore these possible warnings' (09:45:59) scop: f13, ah, okay, I wasn't aware of that (09:46:01) f13: tibbs: it is if we're forcing the use of rpmlint as a review tool. (09:46:09) lutter: f13: the problem with 'visual' is that it depends on how you set tabs in your editor (09:46:45) f13: Run rpmlint on the rpms to examine them for common errors, and fix them (unless rpmlint is wrong, which can happen, too). If you find rpmlint's output cryptic, the -i switch to it can be used to get more verbose descriptions of most errors and warnings. The rpmlint package is available from Fedora Extras. (09:46:46) scop: actually, I don't see "the package has to pass rpmlint" anywhere in the guidelines (09:47:06) tibbs: rpmlint is a tool. It produces warnings for packages which are not in violation of the guidelines, yet these warnings can be useful. (09:47:18) f13: then perhaps we need to make the guidelines more clear on this (09:47:25) tibbs: I don't think there's anything in the guidelines that says "rpmlint must give no warnings". (09:47:29) f13: the common misconception is that the package MUST pass rpmlint. (09:47:45) f13: I"ve seen reviews block on this, and arguments back and forth (09:48:11) tibbs: I use rpmlint as a jumping off point for further questioning. (09:48:31) tibbs: What might be good is if we catalogued rpmlint warnings and their relevance to actual package review. (09:48:49) scop: I think someone was working on such a wiki page not too long ago (09:49:02) f13: tibbs: thats a nice idea (09:49:11) tibbs: I.e. list out some common rpmlint warnings, useful information about getting rid of them, and how important they are in a review. (09:49:16) tibbs: Yes, I'm volunteering. (09:49:20) f13: rock! (09:49:30) f13: that would solve this issue nicely (09:49:38) scop: +1 (09:49:56) f13: scop: did you make a release of rpmlint that shows the line number for the offending tab or space? (09:50:07) scop: not yet (09:50:12) f13: k (09:50:20) f13: does it tell you the line of the tab, or of the three spaces? (09:50:20) tibbs: The only issue is that this ends up having the force of a packaging guideline, so this committee will need to review the document once it gets going. (09:50:21) scop: I think it's about for a new upstream release, I'll ping other folks (09:50:38) f13: I exclusively use tabs to line up things, so no matter what your tab width, the tabs will always line up. (09:51:03) scop: tibbs, works for me (09:51:18) ***scop afk for 3 minutes (09:52:05) rdieter: tibbs++ (09:52:08) tibbs: Just a few minutes until FESCo and I need to make a pit stop. Anything else anyone wanted to discuss? (09:52:26) Rathann: what if rpmlint misidentifies some data files as scripts and gives errors about nonexecutable scripts? (09:52:42) tibbs: Rathann: it's complicated. (09:52:45) thimm: did we want to move the meeting time? (09:53:13) Rathann: because that's what's happening with my latest submission (dx) (09:53:19) lutter: tibbs: I thought htat doc would only help in easing common problems in review; we'd still let the reviewer decide how to deal with rpmlint spew, no ? (and thanks a ton for volunteering to put that doc together) (09:53:36) tibbs: Is anyone good enough with the wiki to block out a table of acceptable times so that people can block in the times that are good for them? (09:54:02) scop: Rathann, you've used rpmlint -i already and read the explanation, right? (09:54:11) scop: one more thing about rpmlint: it can use multiple configs (09:54:11) f13: Rathann: thats because your data file is marked executable. And/or a non-executable file has a #! in the top of it. (09:54:15) abadger1999: thimm: I think so. (09:54:26) tibbs: lutter: Well, the existence of such a document would sort of take some things out of the reviewer's hands. (09:54:30) scop: so we could ship another config file with different set of filters from the default (09:54:36) Rathann: f13: they are not chmod'ed +x, if that's what you mean (09:54:41) abadger1999: Did anyone volunteer to make the wiki page? (09:54:54) Rathann: f13: it's the latter, they begin with a shebang for some reason (09:54:54) tibbs: I guess they're free to ignore it, but then that's not a situation we want to be in. (09:55:05) f13: Rathann: they shouldn't. Get upstream to fix it. (09:55:10) lutter: tibbs: maybe it's easier to figure out once the doc exists (09:55:11) Rathann: o.O (09:55:32) Rathann: I'll try talking to somebody upstream then (09:55:37) tibbs: lutter: I'm going to work on it anyway; if it ends not working out it will still be a useful reference. (09:55:55) tibbs: Rathann: this happens with Python stuff quite often, and there are indeed times when the warning can be ignored. (09:55:58) lutter: tibbs: I would imagine it would say 'this rpmlint error needs to be fixed cause hte guidelines say ...', but it might turn out different (09:56:10) abadger1999: tibbs, thimm: Okay -- I'll make the wiki page for new meeting times. (09:56:20) Rathann: tibbs: it's not a warning, it's an error (09:56:21) lutter: tibbs:absolutely .. it'll help people get more comfrtable with rpmlint either way (09:56:31) thimm: abadget1999: thanks! (09:57:19) thimm: BTW I tabled the discussuion about disttags in rawhide until near-FC6 release (09:58:14) scop: thimm, isn't that something that should be discussed post-FC6 release? (09:58:32) thimm: post FC6 you would have a rawhide with .fc7 tags already (09:58:49) scop: ok, so before that (09:59:05) scop: near-FC6 time is pretty hectic for some people (09:59:20) thimm: We can discuss it earlier or not at all (09:59:33) f13: earlier would be better (09:59:45) scop: next week, then? (09:59:46) f13: I want to branch the FC6 stuff near Test3 timeframe, and let devel/ march ahead toward FC7 (09:59:59) thimm: OK, I'll move the item back to the top (10:00:22) tibbs: Honestly I don't think I have any further objections, assuming I'm remembering things correctly. (10:00:48) thimm: There wasn't a concrete proposal to accept or reject yet ;) (10:01:11) thimm: It's .fc6.89 vs .fc7 for right after release (10:01:16) thimm: But let's discuss next time (10:03:25) thimm: OK, moved back to the original slot