Meeting:Packaging IRC log 20060810

(08:58:59) abadger1999: I just added .pyo files to the schedule which I hope is another EasyFix.
(08:59:59) tibbs: Is the issue well-understood now?  I've been ghosting .pyo files for a long time now and requiring it of the packages I review.
(09:00:10) rdieter: not sure we'll have enough attendee's to get much done, unfortunately. ):
(09:00:10) scop [n=scop]  entered the room.
(09:00:35) slack_: I am here and have lurk mode turned off.  I'm Jack
(09:00:43) tibbs: We know Ralf and Spot are out, but we can still get something done.
(09:01:40) abadger1999: Ghosting seems to have two issues that I can see: 1) causes AVC denials in the log which it seems SELinux isn't able to selectively filter out.
(09:02:55) abadger1999: 2) python won't currently overwrite .pyos so it's possible for a sys admin to "break" python apps by running python -OO [application]  and not have an intuitive way to recover.
(09:03:38) scop: how would that break?
(09:05:03) tibbs: Don't forget 3) requires piling nasty crap into the specfile.
(09:06:08) scop: I think 3) is solvable by a clever "find"
(09:06:08) abadger1999: scop: If the python application depends on docstrings
(09:06:35) tibbs: scop: It's still a lot worse than putting a single directory in %files.
(09:06:47) scop: yep
(09:06:58) abadger1999: -OO will remove the docstrings so the application will break.
(09:07:13) f13: I'm here.
(09:07:35) tibbs: I have no opposition to including .pyo as long as folks who know Python well say it's OK.
(09:07:56) f13: Jeremy Katz is pretty knowledgable IMHO and thinks we should be packaging them.
(09:07:59) tibbs: But remember that rpm will create .pyc and .pyo files for any file ending in .py that it finds, including in /bin.
(09:08:18) scop: yep, that's a rpm bug :)
(09:08:21) abadger1999: tibbs: Hmmm.. bug?
(09:08:35) tibbs: Yes, and filed already some months ago.
(09:08:46) scop: and closed, IIRC...
(09:09:01) abadger1999: Do we want to write a note to rm the .pyc/.pyo in the Python Guidelines?
(09:09:10) abadger1999: (The ones in bin)
(09:09:14) scop: it doesn't help
(09:09:30) abadger1999: Oh. Right because it happens after %install?
(09:09:30) scop: can't be done, it's done by rpm after %install and before %files
(09:09:44) abadger1999: %exclude?
(09:09:52) scop: breaks if they're not there
(09:10:07) rdieter: but they *will* be there... (:
(09:10:11) tibbs: I maintain a package with this problem.
(09:10:26) scop: rdieter, yes, until they one day won't
(09:10:31) tibbs: I touch the files, then let RPM create them if it's going to.
(09:10:35) tibbs: And then %exclude them.
(09:10:49) scop: that works
(09:11:17) abadger1999: What about renaming the files to not have an extension?  (Seen that done in some Core packages)
(09:11:23) scop: the bug is https://bugzilla.redhat.com/182498 , btw
(09:11:30) abadger1999: Which is the lesser evil? :-)
(09:11:47) tibbs: Yep, just found it.  Definitely not closed.
(09:11:48) scop: abadger1999, yes, that's also suggested in #182498 and I don't think it's unreasonable at all
(09:12:23) tibbs: Unreasonable if there's already an expectation that the files exist with those names.
(09:13:01) f13: not so unreasonable if its a bug...
(09:13:07) tibbs: I was maintaining my package before PRM picked up this bad habit...
(09:13:31) f13: but we shouldn't hold up proper packaging because of an existing bug, its just more reason to fix the bug
(09:13:40) f13: and patches are welcome
(09:14:36) scop: abadger1999, so if *.pyo compiled with -O (not -OO) were shipped, apps that have docstring deps would work also with -OO?
(09:15:51) f13: scop: well, running w/ -OO won't create new .pyo files
(09:15:57) abadger1999: scop: Yes.  Because of the python bug.
(09:16:18) abadger1999: bug/feature. Have to file it upstream and see what they say.
(09:16:34) rdieter: let me get this straight, so the proposal (for now) is to simply exclude *all* .pyo files (at least until python and/or rpm is fixed)?
(09:16:50) scop: no, but to include all of them without %ghosting
(09:17:01) rdieter: ok.
(09:17:01) scop: or?
(09:17:06) abadger1999: scop: And work in the sense that docstrings are all there.  It doesn't work in the sense that -OO is then equivalent to -O.
(09:17:19) tibbs: Except ones outside of libdir created due to rpm bugs, I think.
(09:17:21) scop: abadger1999, thanks, got it
(09:17:24) abadger1999: scop: correct.  Include the .pyos instead of %ghost.
(09:18:19) f13: Do we have enough people for a vote?
(09:18:37) f13: All in favor of changing the guidelines to package your .pyo's instead of %ghosting them?
(09:18:42) f13: +1
(09:18:43) abadger1999: +1
(09:18:49) lutter: +1
(09:18:59) rdieter: +1
(09:19:03) tibbs: +1
(09:19:18) scop: reluctant +1
(09:19:33) f13: thats 6, so it passes.
(09:19:42) abadger1999: scop: Do you have a reason, or just gut feeling?
(09:19:48) abadger1999: (For reluctance)
(09:20:05) f13: abadger1999: you'll want to send something to fedora-maintainers about the change, so that we can get feedback during our week long timeout.  That'll get Red Hat packagers attention too.
(09:20:21) scop: it smells like a bug workaround
(09:20:27) abadger1999: f13: Okay.  I'll write it up and send it.
(09:20:45) f13: scop: the reason we're doing this is because the system will get lots of AVC denies as users try to create files in /usr/
(09:21:12) f13: scop: so its better to provide the performance enhanced modules since we create them in our packages.
(09:21:25) f13: I can't think of many cases were peopel don't want their system to run faster.
(09:21:35) scop: yes, I understand, but pedantically thinking, it still doesn't sound like the correct fix to me
(09:21:58) abadger1999: scop: Yep.  To me too.  The python issue might be fixed but there seems to be resistance to "fixing" the SELinux flexibility.
(09:21:59) tibbs: I think it's quite reasonable to expect to see a .pyo wherever there's a .pyc; otherwise, python will just keep trying to create them when it can't.
(09:22:04) rdieter: imo, the best long-term solution is to to what debian does, and (properly) generate .pyo files in %post and/or on demain (ie, as needed)
(09:22:17) rdieter: s/demain/demand/
(09:22:31) tibbs: Doesn't debian neglect to create .pyc files as well?
(09:22:37) f13: rdieter: on demand means users will be trying ot write to /usr/ all the time.
(09:22:49) f13: LOTS of AVCs
(09:22:58) rdieter: by demand, I meant not by users, but when/if ever needed (ie, on python upgrades)
(09:23:07) lutter: and you don't want to leave .pyo files behind when the rpm is uninstalled
(09:23:28) rdieter: lutter: of course, that solution requres %ghost'ing again.
(09:23:42) rdieter: but we're not there yet...
(09:23:47) f13: rdieter: and doens't help when a user would run with OPTIMIZATION
(09:23:59) f13: for all the missing .pyo's you'd get an AVC
(09:24:04) rdieter: f13: the .pyo files would already be there.
(09:24:32) ***f13 gets confused
(09:24:46) f13: oh, I see, do it in %post.
(09:25:01) ***f13 isn't a huge fan of file creation in %post
(09:25:21) rdieter: me neither, but that's the only robust way to do it (afaict)
(09:25:31) scop: that needs to take read-only mounts into account
(09:25:45) rdieter: scop: man, you and your read-only mounts... (:
(09:25:51) scop: :)
(09:25:57) scop: and I don't even use those myself :)
(09:26:04) f13: scop: how could you install something to a read-only mount?
(09:26:20) rdieter: that just seems wrong, you're installing rpms, but to ro mounts? (f13: ++)
(09:26:21) scop: think %{_netsharedpath}
(09:26:36) rdieter: yeah, I'm thinking it's a bad idea. (:
(09:26:55) scop: not a big issue ATM for python because site-lib dirs are in /usr/lib(64), not /usr/share
(09:27:13) rdieter: sorry, digressing... anything else to hash out today?  (pyo is done, right?)
(09:27:16) lutter: stateless has exactly that problem .. you install into an image somewhere and then mount that r/o on lots of clients
(09:27:19) abadger1999: Anyone object to moving on?
(09:27:27) f13: no objections
(09:27:33) ***f13 hates that meeting is during lunch time
(09:27:34) rdieter: move_on++
(09:27:36) abadger1999: Should we just go down the list?
(09:27:48) abadger1999: lutter: Anything to report on Ruby Gems?
(09:27:55) ***scop is afk for ~2 mins
(09:28:19) lutter: abadger1999: nope, nothing .. for now, it's not a very pressing issue
(09:28:51) abadger1999: Okay.  Send an email when the draft is ready?
(09:29:28) abadger1999: f13: What's going on with jpackage naming?
(09:29:59) f13: abadger1999: -ENOFEEDBACK :/
(09:30:01) lutter: abadger1999: yeah, I'll bring it up when I got something .. we might just keep not allowing rubygems packages .. that's what debian does
(09:30:14) f13: abadger1999: i've been told there are concerns, just not what they are.
(09:31:16) abadger1999: f13: Lovely :-/  Well, as long as new java packages don't go in unless they follow the current naming standards they'll have to figure things out eventually.
(09:31:16) rdieter: f13: no feedback means everyone is ok with your proposal to use X.
(09:32:02) rdieter: (:
(09:32:24) abadger1999: Moving on...
(09:32:46) abadger1999: f13: Arch specific scripts?
(09:33:22) f13: havne't gathered a lot of feedback on this either.
(09:33:36) f13: needs more discussion on list
(09:34:04) abadger1999: Did you talk to nasrat about it (I seem to recall we were going to get input from him.)
(09:34:11) tibbs: I rethought my objections to this.
(09:34:41) f13: I honestly don't recall
(09:34:54) rdieter: for the record, I'm (atm) leaning toward making those arch-specific (ie, not noarch), it'll make life simpler (esp buildsystem-wise)
(09:34:56) f13: I haven't thought about it in too long and need to rehash the issue.
(09:35:31) scop: still regarding *.pyo, here's the corresponding spec template change: http://koti.welho.com/vskytta/pyspec.patch
(09:35:51) scop: (includes similar comments as were recently added in the perl template)
(09:36:18) f13: cool
(09:36:21) f13: looks good
(09:36:23) rdieter: scop: thanks, that makes things clearer.
(09:36:44) abadger1999: scop: Looks great.
(09:37:42) abadger1999: f13: Can you bring the script issue back up on the list when you have time and we can see if we still have objections to it?
(09:37:54) f13: yep
(09:38:34) abadger1999: tibbs: Directory ownership
(09:39:02) abadger1999: Have we thought about this more, or not since the last meeting?
(09:39:24) tibbs: I don't recall any additional discussion,
(09:39:44) tibbs: and it would be pretty unfair to proceed when one of the major objectors to any changes (Ralf) isn't here.
(09:40:03) abadger1999: Ah right.
(09:40:08) tibbs: Although I could be misrepresenting Ralf's position; I admit to not fully understanding his objections.
(09:40:50) lutter: even more reason to wait for him
(09:41:00) rdieter: fair enough.
(09:41:24) tibbs: I guess that should have changed from "easyfix".
(09:41:32) abadger1999: Sounds good.
(09:41:42) abadger1999: Okay.  License Tags is next
(09:42:12) tibbs: List discussion seemed to lean towards this being just a superficial description of the license.
(09:42:32) tibbs: That we shouldn't try to get too specific with the license tags.
(09:42:46) lutter: yeah, I don't see that ever being more than an indication
(09:42:50) abadger1999: I tend to agree with that.
(09:43:04) tibbs: So "GPL", not "GPLv2" and "GPLv3", etc.
(09:43:21) abadger1999: The License field shouldn't be misleading, though.
(09:43:24) tibbs: And "BSD", not "BSD with advertising".
(09:44:10) abadger1999: So if GPLv2 and GPLv3 are different enough we would want to differentiate.
(09:44:16) tibbs: And packagers should brave the rpmlint warning rather than lying about the license just to shut it up.
(09:44:17) lutter: for GPL, I could go either way; if it's BSD with modifications, why not just 'BSD variation'
(09:44:23) scop: rpmlint's explanation about the "invalid-license" message needs to be toned down a bit, will have a look
(09:44:53) rdieter: how about s/invalid-license/unknown-license/
(09:45:01) abadger1999: scop: Thanks.  That's one that I often have to write please ignore this warning.
(09:45:40) scop: in general, it's not a good thing to change message identifiers (such as invalid-license) in rpmlint
(09:45:46) scop: because it will break people
(09:45:50) scop: 's filters
(09:46:13) rdieter: ok
(09:46:39) f13: people shouldn't have filters on rpmlint (:
(09:47:07) scop: $ grep addFilter /usr/share/rpmlint/config # :)
(09:47:38) rdieter: so is there a License tag proposal here somewhere?  (:
(09:47:59) f13: scop: sounds like a great way to hide issues :/
(09:48:20) scop: f13, yes, and non-issues :)
(09:48:32) tibbs: No, I haven't written one up.
(09:48:52) f13: scop: IMHO every rpmlint E/W is an issue until a reasonable excuse is given
(09:48:57) abadger1999: It doesn't look like we have any current Guidelines about the Tag; just what rpmlint says.
(09:49:48) tibbs: Then let's get a simple guideline in place and then get rpmlint fixed to match.
(09:50:15) rdieter: sounds reasonable.
(09:50:22) abadger1999: Sounds good.
(09:50:28) tibbs: I'll write something up for next week and present it to the list.
(09:50:38) abadger1999: Cross compilation needs Ralf.
(09:50:41) f13: part of said guideline would be 'If your license is unknown, you must inlude the license in your %doc' ?
(09:51:13) abadger1999: scop: Renaming and EOL
(09:51:40) lutter: f13: I think teh guideline should be 'if upstream has an explicit license file, it must be included as %doc'
(09:52:01) scop: there are rename cases where Provides: is not appropriate
(09:52:09) abadger1999: lutter, f13: I think that portion is almost in the guidelines already.  Maybe clarify that portion?
(09:52:33) f13: lutter: I'm pretty sure there are guidelines to that effect already, however when the license is special, or rather unknown, we should manually include the license if it isn't already.
(09:52:39) scop: actually, "superseded by" is that case
(09:52:50) scop: assuming rename means just that
(09:53:00) lutter: f13: I see what you're saying, yeah, makes sense
(09:54:02) scop: the EOL things should be no-brainers, just process stuff
(09:55:04) abadger1999: http://www.fedoraproject.org/wiki/PackagingDrafts/PackageEndOfLife
(09:55:15) abadger1999: For the EOL process.
(09:56:19) lutter: makes sense
(09:56:32) tibbs: Shouldn't FESCo be doing a policy like that, though?
(09:56:40) tibbs: It doesn't seem to have any relevance to Core.
(09:57:11) f13: makes sense but yeah, doesn't seem much of a Packaging issue
(09:57:19) scop: the Obsoletes/Provides part of the agenda item is a packaging thing
(09:57:47) rdieter: tibbs: I *could* be relavent to Core as well, when/if an upstream product is EOL'd/renamed.
(09:58:08) f13: we do things differently
(09:58:25) f13: we have a package database that keeps track of what packages are in which collections, because trying to just use cvs modules for that is the path to insanity
(09:58:28) rdieter: f13: good point. (:
(09:58:44) tibbs: Core process stuff isn't and doesn't really have to be transparent to Extras folks.
(09:58:54) abadger1999: Is the case just for "superseded"?  Or for both superseded and rename?
(09:59:01) f13: so when a package is removed from Core, we remove it from the collection in the database, then autmoated things just lookup in teh DB what packages should be pulled in.
(09:59:25) scop: abadger1999, whenever something changes in a way that the new package is not a drop-in replacement, IMO
(09:59:58) rdieter: FESCo is starting... (:
(10:00:29) scop: okay, let's defer this
(10:00:41) abadger1999: scop: do you want to write up the one or two lines that describe this?
(10:00:55) scop: will do
(10:00:58) abadger1999: I'm going to move it to the top of GuidelinesTodo for next week.
(10:01:19) abadger1999: (Hey we nearly got through every item this week :-)