From Fedora Project Wiki
(Redirected from Packaging:IRCLog20070213)
(09:03:51 AM) spot: ok.
(09:04:08 AM) spot: my first agenda item:
(09:04:09 AM) spot: http://fedoraproject.org/wiki/PackagingDrafts/ExceptionJPackage
(09:04:10 AM) ecik left the room (quit: "Leaving").
(09:04:45 AM) spot: i reworded the text so it is a policy, not an exception
(09:05:03 AM) spot: i also added a section to clarify how pre-release packages would be handled
(09:06:09 AM) spot: fnasser and the java guys seem ok with this going forward
(09:06:47 AM) rdieter: yay
(09:06:49 AM) ***f13 reads
(09:07:22 AM) f13: oh, I already gave this a +1
(09:07:25 AM) tibbs: I was +1 on the list and I'll reiterate that now. The change to detail prerelease packages seems good to me.
(09:07:32 AM) rdieter: +1
(09:07:43 AM) ***spot is obviously +1 on this
(09:08:04 AM) fnasser__: spot, Is it the one I looked at yesterday plus the rewording for policy?
(09:08:05 AM) abadger1999: +1
(09:08:09 AM) spot: fnasser__: yes
(09:08:10 AM) thimm: 0
(09:08:15 AM) racor: 0
(09:08:24 AM) fnasser__: spot, and of course my +1
(09:08:33 AM) spot: ok, thats +5
(09:09:01 AM) spot: next item: ratify items are all now writeup
(09:10:14 AM) f13: fnasser__: stick around and talk about BuildROot later will you?
(09:10:27 AM) spot: ok, now the floor is open for any items people want to talk about
(09:10:28 AM) fnasser__: f13 OK
(09:10:43 AM) fnasser__: f13, I have to go for lunch now, please ping me
(09:11:12 AM) spot: actually, wait, lets talk about: http://fedoraproject.org/wiki/PackagingDrafts/SpecFileNaming
(09:11:22 AM) fnasser__: f13, Has anyone come up with a better idea? I'd like to see RPM fixed so it could be overriden by the build system :-(
(09:11:33 AM) fnasser__: f13, it is a shame that is broken
(09:11:44 AM) f13: fnasser__: two patches were submitted
(09:11:54 AM) f13: fnasser__: will take time for that to take effect though.
(09:11:55 AM) fnasser__: f13, Oh, I did not know that
(09:12:48 AM) abadger1999: spot: I'm for it of course. No one watching the review bug objected to it.
(09:12:50 AM) fnasser__: f13, Well, having the solution in the way makes things much simple, just transitional measures and everyone is always agreable to those as they know how it will be in the future
(09:12:53 AM) f13: and see the list, buildroot is just a suggestion.
(09:13:03 AM) spot: f13: well, actually, buildroot is mandatory
(09:13:11 AM) f13: spot: oh, you changed that, thats right
(09:13:20 AM) tibbs: Well, the committee changed it.
(09:13:35 AM) f13: nod
(09:13:39 AM) fnasser__: f13, Is it? The reviewer guidelines say it MUST be the one "suggested", so people are rejecting packages based on that (they have no choice, it says there they should)
(09:13:41 AM) thimm: But there is a call for reviewing this decision :)
(09:13:48 AM) f13: spot: +1 to SpecFileNaming
(09:13:53 AM) spot: although, i really do agree that rpm should just be setting it
(09:14:15 AM) fnasser__: spot, +1 to rpm managing buildroot
(09:14:17 AM) thimm: Can we settle on talking spacfilename vs buildroots? :)
(09:14:17 AM) f13: fnasser__: I'm sorry, it is manditory for now.
(09:14:29 AM) spot: ok, vote on the specfilenaming
(09:14:30 AM) spot: +1
(09:14:39 AM) rdieter: +1 SpecFileNaming
(09:14:50 AM) tibbs: +1, although I should point out that there is a way to preserve history across a rename in CVS.
(09:15:01 AM) fnasser__: f13 yeah :-) 150 packages to change. Can we automate this? A big rebuild all with set BuildRoot ?
(09:15:09 AM) thimm: +1
(09:15:13 AM) racor: +1
(09:15:21 AM) spot: ok, specfilenaming passes
(09:15:23 AM) fnasser__: f13, We will never make it to test2 ....
(09:15:38 AM) f13: fnasser__: I'm happy with it changed in CVS, but not necessarily built with it.
(09:15:45 AM) f13: but then, I'm pragmatic
(09:16:09 AM) thimm: What about the kernel's specfile?
(09:16:17 AM) fnasser__: f13, OK, that may be scriptable.
(09:16:22 AM) thimm: Shouldn't it be added to the list?
(09:16:51 AM) spot: thimm: probably.
(09:16:54 AM) abadger1999: thimm: I haven't talked to davej yet as to what he wants to do.
(09:17:10 AM) thimm: k
(09:17:13 AM) abadger1999: But it should fall under this exception as well.
(09:17:24 AM) ***rdieter nods
(09:17:57 AM) spot: ok, any other items for discussion/vote ?
(09:18:03 AM) abadger1999: I started work on another things that came up in a review: http://www.fedoraproject.org/wiki/PackagingDrafts/SourceUrl
(09:18:23 AM) abadger1999: I have to talk to jeremy about finishing the last section, though.
(09:18:27 AM) abadger1999: Hopefully today.
(09:18:44 AM) thimm: buildroots?
(09:18:48 AM) rdieter: I'd like to discuss icon_cache one last time before (likely) semi-permanently tabling-it.
(09:18:54 AM) spot: abadger1999: you may also want to add a section for "when upstream has bad code in it that we strip out of the tarball"
(09:18:59 AM) abadger1999: It's a bit off the top of my head so I'm hoping for input on the lists.
(09:19:11 AM) abadger1999: spot: That's a good suggestion.
(09:19:18 AM) tibbs: abadger1999: I'm definitely for this; it needs to be documented somewhere that people should at least say how to check stuff out of upstream's SCM if there's no tarball.
(09:19:49 AM) spot: ok, lets talk about buildroots for a bit
(09:20:05 AM) fnasser__: abadger1999, I had an idea about the URL one. I forgot to reply to that thread. I was going to propose that the real Source0 line had the macros and a comment was added above it with the no-macro one so one could click and get to the tar ball.
(09:20:29 AM) spot: it seemed abundantly clear to me that the wide range of confusion over buildroots required a short-term and long-term solution
(09:20:30 AM) fnasser__: abadger1999, This way we have safety (the macros make sure we get the right version) and convenience (one can click)
(09:20:30 AM) abadger1999: fnasser__: spectool -g <specfile>
(09:20:35 AM) devrimgunduz [n=Devrim@evim.gunduz.org] entered the room.
(09:20:46 AM) spot: short-term: set a mandatory buildroot to stop the confusion over what is acceptable and what is not
(09:20:53 AM) fnasser__: spot, yes, rpm will peovide long term we hope
(09:20:57 AM) thimm: The confusion comes from suggesting a buildroot at all me thinks
(09:20:59 AM) spot: long-term: patch rpm so that we dont need to set buildroot in the specs
(09:21:13 AM) tibbs: spot: +1
(09:21:31 AM) fnasser__: spot, I would allow it to be there, just overriden
(09:21:35 AM) spot: the current suggested buildroot may be a little much, but it is never technically wrong
(09:21:38 AM) tibbs: Short term, though, I'm happy we're setting something as mandatory.
(09:21:39 AM) fnasser__: spot, Think of shared spec files
(09:21:40 AM) thimm: long-term sounds OK
(09:21:48 AM) fnasser__: thimm, for me too
(09:22:10 AM) thimm: The simple EVR buildroot isn't technically wrong, too
(09:22:15 AM) fnasser__: spot, What about adding userid _and_ arch?
(09:22:17 AM) spot: thimm: thats right
(09:22:35 AM) spot: really, people are adding things like userid and arch to ensure unique buildroots
(09:22:39 AM) spot: there's a better way to do that
(09:22:44 AM) fnasser__: spot, Or just requiring the basic portion and suggestion a better (?) more complete form?
(09:22:47 AM) spot: mkdtemp
(09:22:49 AM) thimm: The truth is that people got confused
(09:22:55 AM) thimm: root was never implying the user
(09:23:03 AM) thimm: It implied (build)root
(09:23:10 AM) spot: yeah, the "-root-" portion of it is a bit useless
(09:23:12 AM) fnasser__: spot, Mandatory: what we have before the userid, suggested either that + userid or that + userid + arch
(09:23:20 AM) tibbs: The point is that without any indication of what a good buildroot is, reviewers don't know what's allowed and what's not. Now we have something that's very clear.
(09:23:22 AM) thimm: So people started to think that /tmp/foo-1-2-root was for the user root
(09:23:54 AM) thimm: And then started to overenineer /root/<code>id un</code>/
(09:23:54 AM) spot: the reason that i proposed that we set it as it is for now is to minimize churn
(09:24:05 AM) spot: either we fix a few hundred packages, or fix a few thousand
(09:24:09 AM) thimm: Let's compromize
(09:24:22 AM) thimm: Put that id-un and the simple EVR as possible buildroots
(09:24:29 AM) thimm: everyone is happy
(09:24:37 AM) spot: i doubt that everyone will be happy
(09:24:46 AM) spot: the problem which will almost certainly arise
(09:24:47 AM) thimm: I will ;)
(09:24:48 AM) rdieter: ok, thimm will be happy. (:
(09:24:52 AM) ***fnasser__ never happens, someone, somewhere won't be :-)
(09:25:05 AM) spot: is from people who will say "but when i go to build a package with the EVR buildroot, it won't be unique for multiple builders"
(09:25:22 AM) thimm: That's not people, that's a single person ;)
(09:25:37 AM) spot: but, to be fair, it is a valid, if obscure, case.
(09:25:54 AM) spot: so, does it hurt anyone to use the id-un buildroot?
(09:25:57 AM) thimm: But more so to build i386 on x86_64, right?
(09:26:04 AM) thimm: And we do ignore that non-conrer case
(09:26:10 AM) f13: I'm pretty tempted to go the route of "DOes it have a buildroot that is technically possible? Yes? Good enough" until the RPM change goes in.
(09:26:11 AM) spot: thimm: that is true.
(09:26:23 AM) racor: sport: Obsure? it simple: Login as one account, build; build segfaults; su to another, build again.
(09:26:24 AM) thimm: f13: +1000
(09:26:29 AM) f13: spot: is 'id-un' the current way?
(09:26:35 AM) spot: f13: yes
(09:26:38 AM) tibbs: f13: If you don't specifically define all terms you use there, I think it's a bad idea.
(09:26:39 AM) f13: racor: simple answer, use mock.
(09:26:49 AM) racor: try a modem.
(09:27:26 AM) f13: racor: local mirror.
(09:27:41 AM) racor: f13: get what i do?
(09:27:45 AM) thimm: Anyone against f13's suggestion?
(09:27:49 AM) abadger1999: racor has a point -- if one user's build exits prematurely, another user can't cleanup the mess.
(09:27:51 AM) racor: s/get/guess/
(09:27:53 AM) spot: thimm: yes
(09:28:00 AM) abadger1999: thimm: -0.75
(09:28:06 AM) spot: we need standardization here
(09:28:09 AM) tibbs: I am against f13's suggestion unless I see a complete description of what buildroots are acceptable.
(09:28:13 AM) spot: there is mass confusion amongst reviewers
(09:28:24 AM) spot: and "do what you feel is ok" is the old policy which worked very poorly
(09:28:30 AM) thimm: spot: If you want to catch all conrer cases you get a buildroot that is more complicated than the specfile
(09:28:33 AM) f13: spot: so if the current way is technically limiting, they I say make it use mkdtemp and be done with it, until rpm takes over.
(09:28:36 AM) thimm: So let's keep it KISS
(09:28:38 AM) tibbs: Right now it is very easy and clear. Packagers can take three seconds to fix specs, or run sed. Why is this even an issue?
(09:28:39 AM) f13: sure there is pain, but it is easily replaceable.
(09:28:45 AM) spot: f13: mkdtemp is the rpm solution
(09:28:49 AM) racor: abadger1999: the same situation happens when sharing machines between coworkers
(09:28:57 AM) f13: spot: mkdtemp can't be embedded in BuildRoot: ?
(09:29:04 AM) racor: one persons builds, forgets to clean up
(09:29:06 AM) spot: f13: no.
(09:29:12 AM) spot: mkdtemp() is a glibc function
(09:29:14 AM) racor: another person tries to build some time later
(09:29:35 AM) thimm: f13: perhaps as a shell call?
(09:29:35 AM) spot: in theory, a really crude binary could be made from it
(09:29:52 AM) thimm: So?
(09:29:59 AM) rdieter: that would be smashing a pin with a sledgehammer, imo.
(09:30:00 AM) thimm: There is no security in using id -un
(09:30:03 AM) f13: isn't there a shell MKTEMP ?
(09:30:12 AM) spot: mktemp yes, mkdtemp no
(09:30:12 AM) thimm: Yes
(09:30:33 AM) f13: spot: mktemp -b
(09:30:33 AM) spot: ahh, mktemp -d
(09:30:34 AM) f13: er -d
(09:30:58 AM) rdieter: interesting.
(09:31:19 AM) spot: i'm not sure how that macro would work off the top of my head
(09:31:25 AM) f13: so we should be able to make use of mktemp -d in Buildroot.
(09:31:32 AM) thimm: I'd go with BuildRoot: %(mktemp -d) or similar
(09:31:47 AM) spot: thimm: well, i think we still want NVR in there
(09:31:55 AM) thimm: Put it as a template
(09:32:00 AM) spot: my patch to rpm did N-V-R-XXXXXX
(09:32:16 AM) thimm: We should use something that is formward compatible
(09:32:34 AM) fnasser__: me thinhs the N-V-R part is nice
(09:32:43 AM) f13: BuildRoot: %{_tmppath}/%(mktemp -d %{name}-%{version}.XXXX)
(09:32:44 AM) ***fnasser__ thinks the N-V-R part is nice
(09:32:58 AM) thimm: BuildRoot: %(mktemp -d /tmp/%{name}-%{version}-%{release}-XXXX)
(09:33:10 AM) spot: thimm: we want to use _tmppath
(09:33:14 AM) rdieter: f13's is better. (:
(09:33:15 AM) spot: in the unlikely event that ever changes
(09:33:23 AM) f13: I haven't tested it, no idea of it works.
(09:33:29 AM) thimm: tmppath needs to be an argument of mktemp
(09:33:31 AM) rdieter: can we guarantee mktemp to be present?
(09:33:32 AM) thimm: Not ouside
(09:33:38 AM) fnasser__: BuildRoot: %{_tmppath}/%(mktemp -d %{name}-%{version}-%{release}-XXXX)
(09:33:43 AM) fnasser__: will that really work?
(09:33:58 AM) spot: BuildRoot: %(mktemp -d %{_tmppath}/%{name}-%{version}-%{release}.XXXXXX)
(09:34:00 AM) rdieter: thimm's right.
(09:34:09 AM) f13: /var/tmp/pungi-0.2.3.9232/etc/pungi
(09:34:10 AM) f13: that works.
(09:34:13 AM) thimm: BuildRoot: %(mktemp -d %{_tmppath}/%{name}-%{version}-%{release}-XXXX)
(09:34:38 AM) f13: why does it need to be an argument?
(09:34:48 AM) thimm: Because mktemp needs to create the dir
(09:34:48 AM) spot: f13: because mktemp looks for a unique dir
(09:34:49 AM) f13: (just curious)
(09:34:53 AM) f13: ah.
(09:34:55 AM) f13: ok.
(09:35:07 AM) tibbs: I'm going to reiterate that I don't care what value we choose as long as it works and it's mandatory so that reviewers can easily check it.
(09:35:13 AM) spot: someone want to go test that quickly? :)
(09:35:18 AM) f13: already dong
(09:35:20 AM) f13: doing
(09:35:24 AM) thimm: I will test taht and repot on list, OK?
(09:35:33 AM) abadger1999: tibbs: +1
(09:35:33 AM) spot: thimm: ok.
(09:35:48 AM) rdieter: tibbs, thimm: +1
(09:35:49 AM) f13: /var/tmp/pungi-0.2.3-9443
(09:35:51 AM) f13: was created from
(09:35:58 AM) f13: BuildRoot: %(mktemp -d %{_tmppath}/%{name}-%{version}-XXXX)
(09:36:22 AM) spot: we need six XXXXXX
(09:36:25 AM) thimm: How did you test?
(09:36:26 AM) f13: k.
(09:36:28 AM) spot: and release. :)
(09:36:31 AM) abadger1999: f13: Is it okay even if mktemp isn't present on the system when mock builds?
(09:36:51 AM) f13: thimm: added it to the spec, rpmbuild -bs foo.spec; rpmbuild -bb foo.src.rpm
(09:36:54 AM) spot: ooh, thats a good point
(09:36:57 AM) rdieter: mktemp needs to be present, or we'll end up with junk buildroot
(09:36:58 AM) abadger1999: Hmm... mktemp is needed by bash.
(09:37:03 AM) tibbs: mktemp is a requirement of /bin/sh, I think.
(09:37:08 AM) rdieter: ok, good.
(09:37:09 AM) abadger1999: Maybe we don't need to worry about that.
(09:37:20 AM) spot: initscripts requires it too
(09:37:24 AM) tibbs: yum erase mktemp wants to delete my entire install.
(09:37:30 AM) f13: yeah, mktemp should be safe
(09:37:38 AM) rdieter: afk 2 min.
(09:37:42 AM) spot: gzip does as well
(09:37:49 AM) racor: Q: what does rpmbuild use to generate its /var/tmp/rpm-tmp.XXXXX?
(09:38:05 AM) f13: uh, mkdir?
(09:38:06 AM) racor: the same mechanism could work for buildroot, too
(09:38:15 AM) f13: oh
(09:38:32 AM) spot: it uses mktemp()
(09:38:57 AM) spot: mkdtemp() is just the directory equivalent
(09:39:10 AM) thimm: OK, it works!
(09:39:29 AM) thimm: I had a suspicion, that %buildroot might be invoced multiplke times
(09:39:37 AM) thimm: That would create several different buildroots
(09:39:41 AM) spot: its not, i checked that yesterday
(09:39:46 AM) rdieter: thimm: ew.
(09:39:48 AM) thimm: But rpm is intelligent and calls it only once
(09:40:02 AM) thimm: We're lucky
(09:40:04 AM) racor: mktemp -d ?
(09:40:06 AM) thimm: Or somone anticipated this :)
(09:40:27 AM) spot: racor: mktemp (the binary) is just a binary which calls the glibc functions
(09:40:38 AM) thimm: So let's go for
(09:40:38 AM) thimm: BuildRoot: %(mktemp -d %{_tmppath}/%{name}-%{version}-%{release}-XXXXXX)
(09:40:50 AM) f13: +1
(09:40:52 AM) racor: +1
(09:40:57 AM) thimm: +1
(09:40:58 AM) spot: +1
(09:40:59 AM) rdieter: +1
(09:41:01 AM) tibbs: +1
(09:41:09 AM) f13: we want nvr in there? nv isn't enough?
(09:41:14 AM) spot: yes, nvr
(09:41:19 AM) thimm: Even name would had been enough
(09:41:28 AM) f13: spot: can I ask why?
(09:41:28 AM) tibbs: So is this now one of two allowed possibilities? Or is this now the mandatory one?
(09:41:33 AM) spot: people will expect NVR
(09:41:36 AM) f13: why?
(09:41:49 AM) spot: because i build lots of packages and it is easy on my human eyes
(09:41:55 AM) rdieter: it makes it clear which NVR build it came from?
(09:42:04 AM) spot: rdieter: exactly
(09:42:10 AM) f13: so its purely a visual thing, rather than a technical thing?
(09:42:10 AM) tibbs: f13: you might as well ask why %{name} is in there.
(09:42:11 AM) thimm: Let's make the current and the new one options
(09:42:25 AM) f13: thimm: the current one is technically broken. why continue using it?
(09:42:28 AM) thimm: Otherwise we would force thousands of packages to modify the specs
(09:42:31 AM) spot: i don't want people to think that the XXXXXX is somehow the release
(09:42:38 AM) thimm: f13: which one?
(09:42:45 AM) spot: (or the version)
(09:42:50 AM) rdieter: the current quasi-mandatory one. (:
(09:42:53 AM) f13: how about instead: Currently one is grandfathered in, new packages _must_ use the new one)
(09:42:58 AM) thimm: OK
(09:43:05 AM) ***rdieter nods
(09:43:06 AM) thimm: That's what I meant
(09:43:09 AM) f13: and old packages should update when they can.
(09:43:17 AM) spot: f13: what about core packages
(09:43:21 AM) abadger1999: As long as the plan is to get this into rpm sometime then yes.
(09:43:22 AM) spot: will they all need to use the new one?
(09:43:25 AM) f13: or when it is appropriate.
(09:43:33 AM) racor: f13: or be sed-scripted
(09:43:34 AM) f13: spot: if Core packages don't match either, they should choose the mktemp version.
(09:43:51 AM) thimm: Do we need to vote on the granfathering rule?
(09:43:53 AM) f13: many have already been changed to the current one.
(09:44:16 AM) rdieter: anyone *not* ok with grandfather clause? (:
(09:44:34 AM) spot: +1 for grandfather for existing packages (and core merge packages)
(09:44:56 AM) rdieter: +1
(09:44:58 AM) racor: +1
(09:45:12 AM) abadger1999: +1
(09:45:29 AM) f13: +1
(09:45:34 AM) spot: ok, thats 5
(09:45:49 AM) tibbs: I have no problem with either grandfathering packages or just allowing both as possible buildroots.
(09:45:53 AM) spot: abadger1999: long-term plan is definitely to put it in rpm
(09:46:00 AM) thimm: +1
(09:46:05 AM) thimm: Sorry, got distracted
(09:46:20 AM) thimm: So, it's +6
(09:46:38 AM) tibbs: Actually 7.
(09:46:48 AM) f13: ok. I need to run. Good meeting guys!
(09:47:30 AM) tibbs: We managed to avoid talking about firmware.
(09:47:33 AM) tibbs: Oops.
(09:47:43 AM) ***rdieter covers ears, la la la.
(09:47:45 AM) spot: tibbs: what about firmware? the board is ok with it
(09:47:48 AM) thimm: Rex told us not to mention the word legal ;)
(09:47:58 AM) racor: LEGAL!
(09:47:59 AM) spot: we have policy in place (and have for some time)
(09:48:39 AM) tibbs: We were asked to come up with Group: and License: tags for firmware on-list, weren't we?
(09:48:45 AM) racor: spot: those were addressing free open-source, the latest proposal was on non-free open-source
(09:48:49 AM) spot: we dont mandate Group tags for anything
(09:49:11 AM) rdieter: racor: actually, it's not OSS either. ):
(09:49:16 AM) spot: racor: the policy doesn't say that, it just says non-exec, non-bin, non-lib, freely redistributable
(09:49:58 AM) spot: as to license tags, i like the tag proposed
(09:49:59 AM) racor: spot: make a head stand, I will vote with -1 to anything sanctoning non-free SW.
(09:50:01 AM) thimm: On Groups: OTOH we don't really care, OTOH anything that goes for other packages goes for firmware, too, pick the closest match
(09:51:02 AM) thimm: racor: spot doesn't possibly know what GErmans mean with making a hand stand
(09:51:25 AM) spot: unless it involves lunch, or shoveling snow...
(09:51:41 AM) spot: are there any proposals we should consider today?
(09:51:49 AM) spot: s/any/any more/
(09:52:06 AM) rdieter: I'd like to take a last stab at icon cache proposal, before nuking it.
(09:52:24 AM) spot: http://fedoraproject.org/wiki/PackagingDrafts/ScriptletSnippets/iconcache
(09:52:32 AM) rdieter: Is there any interest here pursuing it further?
(09:52:45 AM) spot: do you really think that FESCO won't veto it?
(09:53:04 AM) rdieter: now that the "Core cabal" no longer exists... I don't think so. (:
(09:53:10 AM) rdieter: I could be wrong.
(09:53:13 AM) spot: well, the core cabal is in fesco now
(09:53:44 AM) rdieter: frankly, the *only* person/groups ever opposed to this (and xdg stuff in general) has been the Desktop team.
(09:54:11 AM) rdieter: *everyone* else, has been very positive.
(09:54:19 AM) racor: spot: "do a headstand" would have been the correct working, German term to describe "do whatever crazy things you want"
(09:54:39 AM) spot: racor: ah, ok. :)
(09:54:39 AM) abadger1999: This might be an issue:: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=225680
(09:55:28 AM) abadger1999: If you start at the bottom, it's a discussion of interpreting multiple directory ownership.
(09:55:43 AM) abadger1999: Err... multiple packages owning a directory.
(09:56:11 AM) racor: the same pkgconfig/automake/mozilla
(09:56:15 AM) spot: ugh, i think i can clear that up
(09:56:30 AM) spot: it falls under the perl case
(09:56:30 AM) tibbs: We've already established multiple times that single ownership is something we want.
(09:56:39 AM) tibbs: Except for perl and the like.
(09:56:46 AM) spot: if A and B do not depend on each other
(09:56:58 AM) spot: and either A or B could be installed independently of each other
(09:57:02 AM) racor: tibbs: except that it will never work with multile owners
(09:57:08 AM) spot: then both A and B can own the directory
(09:57:25 AM) tibbs: spot: That's not the Perl case, though.
(09:57:42 AM) spot: tibbs: yeah, you're right, sorry
(09:57:58 AM) racor: the perl case is: multiple packages sharing a common parent directory without dependency
(09:58:01 AM) spot: perhaps we need to make that a rule?
(09:59:03 AM) rdieter: A rule based on what you just outlined?
(09:59:12 AM) spot: yes
(09:59:22 AM) rdieter: +1, makes good sense.
(09:59:29 AM) spot: if A and B do not depend on each other, and either A or B could be installed independently of each other, then both A and B can own the directory.
(09:59:52 AM) racor: s/can/must/
(09:59:57 AM) tibbs: But there's a technical reason why directory sharing is bad, and I don't think the proposed rule avoids that technical problem.
(10:00:06 AM) abadger1999: How is this *not* the case we're trying to avoid?
(10:00:17 AM) thimm: spot: Isn't that a logical derivation of "every directory must be owned"
(10:00:19 AM) rdieter: resulting complication: now if C depends on that shared dir, how to handle that? (ie, automake)
(10:00:58 AM) spot: the original intent of the dir ownership rule was to prepare for a day when rpm could handle ordered removals
(10:01:04 AM) spot: currently, rpm doesn't do that
(10:01:23 AM) thimm: doesn't it respect Requires(postun) etc?
(10:01:37 AM) spot: thimm: the answer is "sortof, not really"
(10:01:43 AM) thimm: :)
(10:01:46 AM) rdieter: no, it (apparently) doesn't (so says f13), haven't been able to verify.
(10:01:56 AM) ***spot has verified this several times
(10:02:03 AM) thimm: I n the past PreReq would do the right thing
(10:02:20 AM) thimm: And later it was said that Requires(....) did the same as PreReq and more
(10:02:49 AM) thimm: Anyway is this still on topic with Rex' request?
(10:03:03 AM) rdieter: not really, but that's ok. (:
(10:03:42 AM) spot: so, we can do a few things here
(10:03:54 AM) spot: 1) nuke the directory ownership rules. let anyone own anything
(10:04:03 AM) spot: 2) try to clarify all the corner cases
(10:06:04 AM) spot: thoughts?
(10:06:16 AM) thimm: 3) start with top-down specs?
(10:06:21 AM) tibbs: I think #1 would be bad.
(10:06:30 AM) tibbs: We'd be back to X packages owning /bin and such.
(10:06:37 AM) racor: spot: I once had it written up, but can't find it at the moment
(10:06:38 AM) thimm: What you really want is "a package should not own a directory if that directory will be present after this package's rmeoval"
(10:07:06 AM) thimm: "present" means in a packaged form
(10:07:20 AM) spot: thimm: thats the idea, but it gets complicated when A or B can be installed independently or simultaneously
(10:08:01 AM) rdieter: and more so when/if C depends on that "shared" item/dir.
(10:08:48 AM) racor: rdieter: then C must own dir/item
(10:09:12 AM) spot: let me think on this and write up a draft
(10:09:20 AM) rdieter: racor: no way, ie, automake case, you want all pkgs installing automake macros to own /usr/share/aclocal?
(10:09:27 AM) thimm: spot: why, if they are indepednent, then they need to own it
(10:09:28 AM) racor: yes.
(10:09:45 AM) thimm: It's a derivation from the above + "every dir/file should be owned"
(10:09:52 AM) racor: the same wrt to pkgconfig, mozilla etc.
(10:09:54 AM) abadger1999: spot: There's been many threads on this subject.
(10:10:23 AM) abadger1999: I just found two on gmane that mention umask and directory permission issues.
(10:10:52 AM) ***spot has to go now
(10:10:55 AM) rdieter: right, when a directory is *unowned* umask rears its ugly head.
(10:11:01 AM) spot: if i dont eat, i'll pass out. :/
(10:11:25 AM) thimm: Let's wrap it and good lunch!
(10:11:42 AM) thimm: (or breakfast or whatever in your TZ ;)
(10:11:43 AM) abadger1999: (One of the directory issues is when two packages own a directory but disagree on owner/permissions.)
(10:11:48 AM) abadger1999: k
(10:12:04 AM) rdieter: me too, I'll table icon issue for one more week, unless folks here this we should just drop it.
(10:12:34 AM) rdieter: opinions? I think it's still worth (trying to address/fix), even if there is pushback.
(10:13:07 AM) rdieter: s/this/think/
(10:13:32 AM) tibbs: I agree that it needs to get fixed, but I'm not really sure that it ever will be.
(10:14:07 AM) abadger1999: rdieter: ~ Can we appease the desktop people?
(10:14:12 AM) rdieter: I'm only talking about fixing the Packaging guidelines, everything else it out of our hands.
(10:14:19 AM) abadger1999: If we can then we can work on it some more.
(10:14:47 AM) tibbs: But in this case case the guidelines just include cruft to work around gnome inadequacies.
(10:14:58 AM) abadger1999: If we can't we have to decide if we have a case to take to someone who can override the veto.
(10:15:01 AM) tibbs: gnome people say they're needed.
(10:15:15 AM) rdieter: abadger1999: I don't think FESCo will veto it.
(10:15:23 AM) thimm: rdieter: I think it was shown that it is currently broken, so we really need your fixes to the guidelines
(10:15:39 AM) tibbs: Hmm, how is it actually broken now?
(10:15:45 AM) rdieter: imo, the only reason it was vetod before was because Jesse pretty much had single-hand veto power.
(10:15:51 AM) thimm: blizzard posted on fedora-packageing about it
(10:16:55 AM) rdieter: tibbs: hothing is strictly broken, I'm just arguing toolkit-specific optimization hacks don't belong in the guidelines.
(10:17:12 AM) rdieter: esp, when other, much better solutions to the same problem exist.
(10:17:44 AM) rdieter: esp when said hacks involve 100's of packages.
(10:17:51 AM) tibbs: I agree with that arugment, but perhaps thimm knows of something that's actually busted.
(10:18:38 AM) rdieter: thimm: I don't recall blizzard posting on the subject, can you jog my/our memories?
(10:18:49 AM) thimm: I'm looking it up ...
(10:19:12 AM) rdieter: mclausen *claimed* there existed a crasher bug when/if the gtk icon cache wasn't current.
(10:19:37 AM) thimm: sorry, it wasn't blizzard, it was Chris Aillon
(10:19:47 AM) rdieter: but, I'd argue, again, that's a bug to be fixed elsewhere, outside the scope of packaging.
(10:19:49 AM) tibbs: rdieter: Any idea what KDE does with this stuff? Does it use the cache? If so, does it care if it's out of date.
(10:20:08 AM) rdieter: no, this is a gtk-specific icon cache we're talking about here.
(10:20:24 AM) rdieter: kde has it's own implementation (it generates a cache on first lookup/load).
(10:20:41 AM) thimm: Here is the quote for the list:
(10:20:41 AM) thimm: Rex Dieter wrote:
(10:20:41 AM) thimm: >imo, ldconfig example isn't a good one, but I get your point.
(10:20:41 AM) thimm: >Difference being here, messing with ldconfig can horribly break
(10:20:41 AM) thimm: >things. A stale iconcache doesn't break anything, at worst only
(10:20:41 AM) thimm: >affects app startup time (a little).
(10:20:43 AM) thimm: Stale icon cache has been known to break apps, though. nm-applet is one
(10:20:45 AM) thimm: of them.
(10:21:13 AM) rdieter: ok, that was the case for which I spoke. It was Chris A, not mclausen.
(10:21:37 AM) rdieter: irrelevent still, imo.
(10:21:38 AM) abadger1999: Okay -- that's not a crasher AFAIK.
(10:21:50 AM) abadger1999: It's a matter of not getting the icons to show up.
(10:22:28 AM) abadger1999: rdieter: How does kde manage its cache? Is it per user?
(10:22:43 AM) ***f13 doesn't really see the value in introducing packaging guidelines that we know will introduce performance problems.
(10:22:44 AM) rdieter: abadger1999: per user, pretty much, yes.
(10:23:18 AM) rdieter: f13: I'd argue (as I said in the past), if a proposal came in *today* to include gtk-update-icon-cache to the guidelines...
(10:23:23 AM) rdieter: imo, it would not pass.
(10:23:33 AM) tibbs: Besides, this is actually removing crap from the guidelines.
(10:23:46 AM) rdieter: better solutions, implementations exist.
(10:24:26 AM) f13: rdieter: better for Gnome? That's not what our Desktop folks think.
(10:24:27 AM) rdieter: the current implementation is fragile, at best.
(10:24:37 AM) abadger1999: f13: I kinda see rdieter's point. Really, using gtk-update-icon-cache is a huge exception in our guidelines: "Follow the f.d.o icon cache spec. As a workaround for a gtk limitation, you must also run gtk-update-icon-cache"
(10:25:27 AM) rdieter: f13: Desktop folks agree the current situation sucks, they just haven't come up with anything better, yet.
(10:25:41 AM) f13: rdieter: and your proposed change is not better.
(10:25:47 AM) abadger1999: I'm not sure I agree that it should be removed without a replacement but I'm not entirely happy with the guideline.
(10:25:54 AM) tibbs: It's certainly better from a packaging standpoint.
(10:25:54 AM) f13: so we're either going to have to leave it in the guidelines, or except it every single review.
(10:26:26 AM) f13: also, portland standards are not widely accepted as standards.
(10:26:40 AM) rdieter: I'm ok with allowing the use of gtk-upate-icon-cache as on option, but that kinda defeats the point of it.
(10:26:42 AM) abadger1999: f13: Portland is not in the proposal.
(10:27:14 AM) rdieter: f13: ha, xdg is accepted by pretty much everyone *except* Fedora's Desktop team (and that's part of the problem, I perceive here).
(10:27:23 AM) f13: rdieter: purposfully breaking the Gnome desktop also defeats the purpose of the Best Practices guidelines.
(10:27:31 AM) rdieter: nothing breaks!
(10:27:37 AM) f13: its a performance hit.
(10:27:45 AM) rdieter: right.
(10:27:45 AM) f13: an unnecessary one.
(10:28:09 AM) abadger1999: Not if you regenerate the cache outside of the packaging.
(10:28:25 AM) rdieter: f13: I understand your prespective, and I respect you opinion, even if I disagree with it.
(10:28:37 AM) f13: rdieter: given that no small part of our desktop team is also the upstream gnome, I kind of wonder if upstream gnome also has the same thoughts on portland.
(10:29:26 AM) rdieter: f13: Aaron touched on that at FUDCon, gnome's participation in freedesktop.org has waned lately.
(10:29:46 AM) rdieter: and that's not good for anyone.
(10:30:17 AM) rdieter: After j5 (and havok) left to work on mugshot, that is.
(10:30:35 AM) f13: j5 doesn't work on mugshot
(10:30:53 AM) rdieter: ok, but not gnome anymore, apparently.
(10:30:58 AM) abadger1999: rdieter: You mean owen and havoc
(10:31:01 AM) f13: but while it is unfortunate, perhaps it is a sign that they didn't agree with the thigns being proposed at fd.o
(10:31:42 AM) f13: well, the Gnome board had elections, and j5 stepped down, making room for other RH folks. j5 still does upstream for dbus, and various other things, but mostly he's workign on OLPC
(10:31:43 AM) rdieter: havoc (and owen or who ever, I'm bad with names sometimes), were/are still highly supportive.
(10:31:54 AM) f13: owen/havoc are now with mugshot, yes.
(10:32:03 AM) rdieter: j5 too.
(10:32:11 AM) f13: its easy to be supportive without actually looking at whats being done.
(10:32:53 AM) f13: not that I look myself, i just hear folks still knee deep in it complain a lot.
(10:33:18 AM) rdieter: Frankly, John(?) and mclausen said they considered kde and gnome to be completely separate platforms, like Windows,, MacOS.
(10:33:25 AM) f13: people on the outside say things like LSB are a great idea and they're very supportive of it, never mind the fact that LSB comes up with some really really crackrock stuff that nobody in their right mind would follow.