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