From Fedora Project Wiki
(Redirected from Packaging/Minutes20070313)
Fedora Packaging Committee Meeting of {2007.03.13}
Present
The entire committee was present:
- AxelThimm (normally
thimm) - DavidLutterkort (
lutter) - JasonTibbitts (
tibbs) - JesseKeating (
f13) - RalfCorsepius (
racor) - RexDieter (
rdieter) - TomCallaway (
spot) - ToshioKuratomi (
abadger1999) - VilleSkyttä (
scop)
thimm lutter tibbs f13 racor rdieter spot abadger1999 scop
Writeups
The following drafts have been accepted by FESCO and are to be written into the guidelines:
- Firmware Packaging guidelines: https://www.redhat.com/archives/fedora-packaging/2007-February/msg00292.html
- Disallowing %config files under /usr: PackagingDrafts/UsrConfigs
Votes
The following proposals were considered:
- Keeping the meeting time at 17:00 UTC in spite of the early US switch to DST.
- Accepted
- No formal vote, no dissent recorded.
- Some wiki pages indicated 16:00 UTC from before the last switch from DST; these have been corrected.
- Codifying when it is safe for scriptlets to write to various directories: PackagingDraft/ScriptletsWriteDirs
- Accepted.
- Voting for: thimm lutter tibbs f13 rdieter spot abadger1999 scop
- Voting against: racor
- Note that the draft is in PackagingDraft instead of PackagingDrafts; it may move in the future.
- Prepping BuildRoot for %install: PackagingDrafts/BuildRootHandling
- Multiple versions were discussed:
- A version requiring deletion and immediate creation of the buildroot was rejected.
- A version requiring deletion of the buildroot was accepted. (This codifies existing practise.)
- Voting for the final proposal: rdieter spot racor abadger1999 tibbs f13 lutter scop (at +1/2)
- Voting against the final proposal: thimm
Other Discussions
The following additional items were discussed; see the logs for full details.
- Guidelines for packaging Ruby Gems: PackagingDrafts/RubyGems
- Modifying the Perl specfule template to include
BuildReqires: perl(ExtUtils::MakeMaker)
IRC Logs
Note that discussion of the Ruby Gems issue continued beyond the end of the meeting; the entire log has been included.
[11:56] *** spot sets the channel topic to "FPC: Issues being addressed: http://fedoraproject.org/wiki/Packaging/GuidelinesTodo".
[11:57] <spot> ok, lets try this again. :)
[11:58] <abadger1999> here
[11:58] <f13> here
[12:00] <thimm> Hi all
[12:01] <spot> lutter, rdieter, tibbs ?
[12:01] --> scop has joined this channel (n=scop@cs27014175.pp.htv.fi).
[12:01] <rdieter> here.
[12:01] <tibbs> Yep.
[12:01] *** spot gives scop the permission to talk.
[12:01] <lutter> spot: I am here
[12:01] <scop> here
[12:01] <spot> 8 out of 9, not bad. :)
[12:01] <spot> ok, lets get started.
[12:01] <spot> first item: meeting time
[12:02] * f13 votes to not move it.
[12:02] <spot> some of the wiki pages say 1600 UTC, but it was scheduled for 1700 UTC (and people showed up at 1700)
[12:02] <f13> I'm tired of having to eat my lunch through the meeting.
[12:02] <spot> i think i just need to correct the wiki pages to be 1700 UTC
[12:02] * rdieter doesn't care, either is fine.
[12:02] <lutter> this works for me
[12:03] <abadger1999> I'm fine either way.
[12:03] <scop> ditto
[12:03] <tibbs> I registered 1700 as the meeting time for this channel because that's when we've been holding it.
[12:03] <spot> ok, then 1700 it is.
[12:03] <spot> i'll fix the wiki page
[12:03] <spot> Next: Disallow %config in /usr and Firmware Guidelines were approved by FESCO
[12:03] <spot> they've been marked as writeup
[12:04] <spot> Next item: http://fedoraproject.org/wiki/PackagingDraft/SciptletsWriteDirs
[12:04] <spot> Aka: Only allow writing in %buildroot during %install
[12:05] <thimm> (and %clean ;)
[12:05] <tibbs> We discussed this at length some time ago, didn't we?
[12:05] <spot> tibbs: last meeting we talked about it, thimm wrote a draft for it
[12:06] <tibbs> I must be thinking of something else, then.
[12:06] <thimm> I ned to afk for 1 moment, +1 if it's being voted on
[12:06] <lutter> but it seems pretty uncontroversial
[12:07] <spot> i'm not entirely sure what problem it solves, but since we usually destroy the buildroot in %install, i'm ok with it.
[12:07] <tibbs> OK, I'm not clear: what's the difference between buildroot and _builddir?
[12:08] <tibbs> Oh, _builddir is /tmp. Sort of a weird name for /tmp.
[12:08] --> racor has joined this channel (n=rc040203@HSI-KBW-082-212-056-027.hsi.kabelbw.de).
[12:08] <scop> ?
[12:08] *** spot gives racor the permission to talk.
[12:08] <scop> rpm -E %{_builddir}
[12:08] <racor> grumble - Who changed the channel?
[12:08] <spot> racor: uh, we did? last meeting?
[12:08] <f13> racor: we voted on it last meeting
[12:08] <tibbs> Even voted on it.
[12:09] * thimm is back
[12:09] <f13> racor: we're trying to consolidate all FEdora meetings into #fedora-meeting
[12:09] <abadger1999> racor: We're on the first item: http://fedoraproject.org/wiki/PackagingDraft/SciptletsWriteDirs
[12:09] <spot> _builddir isn't usually /tmp (I guess it could be)
[12:09] <thimm> tibbs: _builddir is where %prep drops the source
[12:10] <spot> its usually %{_topdir}/BUILD
[12:10] <tibbs> Ah, I have it defined to /tmp.
[12:10] <tibbs> So ignore me, then.
[12:11] <spot> alright, should we vote on http://fedoraproject.org/wiki/PackagingDraft/SciptletsWriteDirs ?
[12:11] <rdieter> +1
[12:11] <lutter> +1
[12:11] <thimm> +1
[12:11] <spot> +1
[12:11] <f13> +1
[12:11] <abadger1999> +1
[12:11] <tibbs> +1
[12:11] <scop> +1
[12:11] <f13> abadger1999: you killed the cascade effect (:
[12:12] <abadger1999> I'll have to be quicker on the keyboard :-)
[12:12] <spot> racor: would you like to vote on this?
[12:12] <tibbs> Hmm. %check can't write to buildroot?
[12:12] <scop> no
[12:12] <tibbs> Yes, that makes sense now.
[12:12] <tibbs> Had to think about it for a second.
[12:13] <lutter> tibbs: it shouldn't ... that basically means that unit tests want to scribble all over the fs
[12:13] <racor> -1
[12:13] <spot> racor: ok, why?
[12:13] <racor> firstly, i've got to read
[12:14] <racor> secondly, I have packages which currently write to buildroot during %build
[12:14] <racor> thirdly, I fails to see the benefits
[12:14] <spot> racor: why do they write to buildroot?
[12:14] <spot> (during %build)?
[12:14] <racor> because they do not fit into the %prep,%build,%install scheme
[12:15] <racor> they build and install at the same time
[12:15] <lutter> racor: so %install doesn't kill the buildroot either ?
[12:15] <spot> racor: umm, if they dont fit the scheme, couldnt you just move those writes to %install ?
[12:15] <thimm> or to a tmp dir and then cp to %buildroot
[12:15] <lutter> that's what I do with rubygems .. build/install is kinda munged together so I do it all in %install
[12:15] <rdieter> this like any other rule, can have valid exceptions.
[12:16] <racor> thimm: this is exactly, why this proposal is useless
[12:16] <spot> rdieter: +1
[12:16] <racor> the separation into %build vs. %install is arbitrary
[12:16] <f13> racor: not for the vast majority of our packages.
[12:16] <scop> btw, calling %prep, %build and friends "scriptlets" sounds odd to me
[12:16] <racor> f13: Yes for GNU packages
[12:16] <thimm> rdieter: This rules gives mopre safety over buildroot usage
[12:17] <f13> if every best practice had to be perfect for it to be in effect, we'd not have any rules.
[12:17] <scop> aren't %post and friends scriptlets, and %prep, %build etc "sections"
[12:17] <f13> racor: 'GNU' has nothing to do with it.
[12:17] <racor> f13: Vast majority == there are exceptions
[12:17] <thimm> scop: "odd name": any better suggestion?
[12:17] <scop> "sections"
[12:17] <spot> racor: there are exceptions to everything we've ever written.
[12:17] <abadger1999> scop: +1
[12:17] <f13> racor: yep, many of our rules can have reasonable exceptions.
[12:17] <racor> f13: wrong, the configure && make && make install is GNU
[12:17] <spot> the guidelines cover the general case for packaging
[12:17] <f13> racor: thats not what I'm talking about.
[12:17] <thimm> scop: sections are subpackages, as well
[12:18] <racor> f13: exceptions == lack of generality
[12:18] <scop> thimm, ?
[12:18] <spot> if you have a corner case that doesn't make sense to follow the guideline, use your own common sense.
[12:18] <f13> racor: even pure python software has a build vs install step.
[12:18] <scop> "build phases"?
[12:18] <thimm> scop: I like that
[12:18] <thimm> do we need to revote on rewording?
[12:18] <f13> +1 to build phases
[12:18] <thimm> +1
[12:18] <spot> +1
[12:19] <racor> f13: define build phases
[12:19] <spot> %prep, %build, %install, %clean and %check
[12:19] <f13> as listed in the Draft.
[12:19] <racor> when being consequent, you'd have to disallow compilation during %install
[12:19] <racor> then is package, I am referring to would be dead
[12:20] <racor> s/is/this/
[12:20] --> GeroldKa has joined this channel (n=GeroldKa@pD9E92FC8.dip0.t-ipconnect.de).
[12:20] <rdieter> that would be a natural extension of this..., but as folks pointed out, exceptions *are* ok.
[12:20] <f13> this package you're referring to would have a corner-case exception.
[12:20] <GeroldKa> hi all
[12:21] <f13> these are GUIDELINES, as in best practices, but not hard/fast YOU MUST DO IT THIS WAY OR ELSE things. Please try to understand that we're trying to clarify the mass majority here, and that there can and will be reasonable exceptions to many of our best practices.
[12:21] <rdieter> f13: +1
[12:22] <spot> i don't think its even possible to have a grand unified packaging guidelines that covers every possible corner case.
[12:22] <racor> then weaken all this and rephrase this into into "should not write to"
[12:22] <spot> racor: i don't think it is relevant to do that for 0.0001 % of the packages in the tree.
[12:22] <spot> we'll just note those as valid exceptions
[12:22] <racor> spot: only because we are about to over-engineer details
[12:23] <lutter> racor: think of the novice packager that needs some guidance when they could go either way ... that and uniformity as much as possible are teh big values of guidelines
[12:23] <spot> alright, well, racor's dissent is noted on the record.
[12:23] <spot> the vote passes, lets move on
[12:24] <racor> lutter: exceptions are the reason why people accuse the FPG to be "nuts"
[12:24] <spot> Next item: http://fedoraproject.org/wiki/PackagingDrafts/BuildRootHandling
[12:24] <spot> Require that BuildRoot be deleted, then recreated immediately at the beginning of %install
[12:24] <tibbs> This will require changes to essentially every package.
[12:24] <spot> yep. but there is a valid race condition here.
[12:24] <rdieter> racor: You mean we're not nuts? :)
[12:25] <tibbs> I'm not sure I see the supposed race condition as a cause for concern, though.
[12:25] <f13> crapsake. Another friggin rule about buildroot?
[12:25] <thimm> tibbs: security
[12:25] <rdieter> it's a small/trivial corner case, but it's not intrusive, so +1.
[12:25] <thimm> +1
[12:25] <spot> well, we never actually passed a guideline saying that you need to delete the buildroot at the beginning of %install
[12:25] <lutter> what about existing packages ?
[12:26] <spot> i figured, if we're going to do it, we might as well do it right.
[12:26] <tibbs> thimm: That's not a terribly valid argument given that we allow a predictable buildroot in the first place.
[12:26] <thimm> It's *only* for predictable buildroots
[12:26] <thimm> And our most preferred one is non-predictable
[12:26] <racor> rdieter: no, I means people are accussing the FPGuidelines to be "nuts". The same logic people apply to German Tax Laws - Without being a tax lawyer you can't understand them.
[12:26] <thimm> And together with the vote we just had it also works even with stepped builds
[12:27] <-- mdomsch has left this server ("Leaving").
[12:27] <tibbs> Besides, I don't see how this actually closes the race. It shrinks it, but does not close it.
[12:27] <spot> tibbs: mkdir on the BuildRoot will fail if it exists
[12:27] <thimm> It's not mkdir -p , but mkdir
[12:27] <spot> and the rpm build will stop
[12:27] <spot> thus, the race is prevented
[12:27] <thimm> spot: maybe suggest a one-liner instead?
[12:27] <racor> spot: /var/tmp on nfs?
[12:28] <scop> it will also fail in setups that used to work before
[12:28] <thimm> e.g. rm -rf %{buildroot}; mkdir %{buildroot}
[12:28] <f13> racor: surely /var/tmp isn't your buildroot.
[12:28] <spot> /var/tmp isn't a permissable Fedora BuildRoot anyways
[12:28] <tibbs> It just seems to me that if there's a valid security issue here, it shouldn't be fixed by hacking up every single specfile.
[12:28] <racor> /var/tmp is the default %{_tmppath}
[12:29] <spot> tibbs: ok, how should we fix it?
[12:29] <tibbs> The security hole would seem to me to be in rpm itself.
[12:29] <f13> racor: this isn't the tmppath.
[12:29] <f13> racor: this is the buildroot
[12:29] <racor> rpm --showrc | grep tmppath
[12:29] <f13> tibbs: +1 for punting the issue to rpm to fix it there.
[12:29] <spot> tibbs: it lies in the fact that after i rm -rf the buildroot, if someone comes in and makes it (but with permissions favorable to them)
[12:29] <racor> -14: _tmppath %{_var}/tmp
[12:30] <f13> racor: I really don't see what your point is here.
[12:30] <spot> then if i do mkdir -p %{buildroot}/foo
[12:30] <f13> racor: we're talking about %{buildroot}, NOT tmppath
[12:30] <spot> it will succeed, and i can insert bad things into buildroot
[12:30] <tibbs> It just seems laughable that every single spec needs two lines to set up the buildroot and worry about this security thing when rpm should just be doing it.
[12:30] <racor> BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-....
[12:30] <spot> this really isn't an rpm problem, unless rpm starts nuking buildroot as part of %install
[12:31] <scop> I don't think a plain "mkdir" is a good solution
[12:31] <f13> racor: again, your point? We're talking about the final dir, not the base part of the path.
[12:31] <tibbs> But then if every single spec already cleans buildroot then I guess we have little choice but to do something like this.
[12:31] <lutter> scop: do you mean there should be a macro that does the rm && mkdir ?
[12:31] <thimm> scop: why?
[12:31] <scop> lutter, no
[12:32] <racor> file locking, parallel builds w/ nfs mounted /var/tmp
[12:32] * f13 is still not seeing the point.
[12:32] <scop> because it will break setups where not all parent paths of %buildroot exist
[12:32] <f13> racor: all your builds use the same exact %{buildroot} ?
[12:32] <rdieter> scop: I don't see that, example?
[12:32] <lutter> racor: don't do that then .. we are talking about making it possible for people to avoid a race and setup builders securely, not that every setup under the sun will suddenly be secure
[12:32] <racor> f13: The time slots/delays are much bigger
[12:32] <scop> example: define _tmppath as /var/tmp/%(%{__id_u} -n)
[12:33] <f13> racor: much bigger than what?
[12:33] <scop> do not create the dir, then try to build a package which has BuildRoot: %{_tmppath}/$whatever
[12:33] <rdieter> scop: ah, trading one corner case for another. (:
[12:33] <racor> f13. I give up
[12:33] <thimm> scop: for such buildroot the user should create the top folder
[12:33] <scop> thimm, I disagree
[12:33] <thimm> Otherwise it would be even easier to take over
[12:34] <rdieter> scop: I don't think it unreasonable to assume buildroot exists prior to building a pkg, but that's just me.
[12:34] <spot> scop: ok, suggestions on other ways to handle this race condition?
[12:34] <rdieter> scop: sorry, buildroot (parent).
[12:34] <f13> rdieter: it may not the very first time you build a package on a system.
[12:34] <scop> dunno, mkdir $(dirname %buildroot) && mkdir %buildroot
[12:34] <thimm> scop: BTW the preferred mktemp buildroot alsreday creates the parent
[12:35] <scop> eh, no, that's no better
[12:35] <thimm> Aynway, no suggested buildroot in the guidelines has that depth in hierarchies
[12:36] <thimm> Any complicated user setup (like /var/tmp over nfs ...) needs special attention by the user.
[12:36] <thimm> So let's go for spot's suggestion
[12:36] <thimm> +1
[12:36] <scop> -1
[12:36] <f13> seriously, do we have nothing better than to argue over trying to protect a rather slim security problem?
[12:36] <abadger1999> -1
[12:36] <rdieter> I'm not even sure this is significant enough to even worry about. ???
[12:36] <f13> where sites that may have this problem cna define their own buildroot macro anyway?
[12:36] <racor> -1
[12:37] <thimm> rdieter: probably not, but it's on the table now, so we need to decide +1 or -1
[12:37] <spot> ok. how about just rm -rf %{buildroot} ?
[12:37] <spot> without the mkdir?
[12:37] <scop> ?
[12:37] <spot> this has been "accepted standard" without ever being documented
[12:37] <thimm> That doesn't really close the race
[12:38] <spot> it absolutely doesn't.
[12:38] <tibbs> rpmlint checks for that, doesn't it?
[12:38] <lutter> f13: how do the fedora builders guard against a package trying to attack another one that's building ?
[12:38] <abadger1999> spot: +1 for that half of the proposal.
[12:38] <spot> tibbs: yes.
[12:38] <rdieter> ugh, +1 (only since it's not documented)
[12:38] <f13> lutter: mock.
[12:38] <racor> this issue has never been a real problem
[12:38] <tibbs> Frankly I would prefer that rpm do this properly itself.
[12:38] <lutter> f13: all builds are serialized ?
[12:38] <rdieter> tibbs: of course, any suggestions/patches? :)
[12:38] <racor> tibbs: Yes, that's where a fix should go to.
[12:38] <tibbs> We do so many rpm patches via guidelines.
[12:38] <f13> lutter: yes, mock won't allow you to do multiple builds in the same chroot at the same time.
[12:39] <thimm> tibbs: rpms should not really mess up with buildrots
[12:39] <abadger1999> tibbs: +1 when we can get that in.
[12:39] <thimm> rpm is generic enough to do other things as well
[12:39] <thimm> So it really is in the specfile's domain to handle this
[12:39] <tibbs> rpm should provide is with a clean, secure buildroot.
[12:39] <thimm> If a buildroot is needed at all
[12:39] <spot> everytime i even think about patching rpm, I get dragged into a pit full of crap with jbj swimming in the middle
[12:39] <thimm> rpm is generic
[12:39] <rdieter> baby steps...
[12:40] <racor> tibbs: and atomic dir erasure/creation
[12:40] <spot> tibbs: feel free to submit rpm patches. if rpm makes these guidelines obsolete, awesome.
[12:40] <thimm> OK, let's please vote on the original proposal
[12:40] <thimm> If it doesn't pass we vote on the rm only stuff, ok?
[12:40] <f13> -1
[12:40] <lutter> -1 on the original
[12:40] <thimm> +1
[12:40] <tibbs> -1
[12:40] <abadger1999> -1 on original
[12:40] <f13> I'd rather not spend time on this issue which effects only a small usage case.
[12:40] <rdieter> +1
[12:40] <spot> i'm rewriting the draft
[12:40] <f13> since we can't fix it correctly
[12:41] <spot> http://fedoraproject.org/wiki/PackagingDrafts/BuildRootHandling#preview
[12:41] <f13> and we could spend endless days discussing the color of the shed.
[12:41] <rdieter> f13: ++
[12:41] <lutter> and there's a perfectly good workaround
[12:41] <spot> this is the amended draft, just rm -rf buildroot
[12:41] <f13> *punt* as not our problem and have rpm fix it.
[12:41] <thimm> lutter: which?
[12:41] <lutter> thimm: use mock and clean build roots for each build
[12:41] <rdieter> spot: +1
[12:42] <f13> spot: This is required to ensure that the BuildRoot exists, and is empty. <-- that text looks weird when all we do is remove it.
[12:42] <thimm> lutter: criticism can from people using it w/o mock
[12:42] <rdieter> (having a clean buildroot really should be documented)
[12:42] <thimm> If we rely on mock we could just drop all Buildroot issues
[12:42] <spot> f13: s/exists, and//
[12:42] <f13> spot: if there is no mkdir, what makes the buildroot?
[12:43] <lutter> thimm: it's tempting :)
[12:43] <thimm> f13: You voted against the mkdir
[12:43] <spot> f13: some packages make the buildroot with make install
[12:43] <abadger1999> Something along the lines of: "This is to ensure the buildroot will be created fresh during the %install section"
[12:43] <spot> abadger1999: thats a much better section.
[12:44] <f13> thimm: I voted against there being any thing whatsoever in our guidelines about this.
[12:44] <scop> abadger1999, but there's the race... so rm -rf doesn't ensure it being created fresh
[12:44] * scop ducks
[12:45] <spot> alright. lets vote on this: http://fedoraproject.org/wiki/PackagingDrafts/BuildRootHandling
[12:45] <rdieter> +1
[12:45] <spot> +1
[12:45] <racor> +1
[12:46] <abadger1999> +1 since it's already the de facto standard.
[12:46] <spot> scop: (to be fair, it doesn't say "created fresh by the intended build user") ;)
[12:46] <tibbs> +1 but I still wish rpm would do this.
[12:46] <spot> tibbs: feel free to patch rpm to do it.
[12:46] <thimm> -1
[12:47] <f13> wait.
[12:47] <f13> so this doesn't actually solve anything
[12:47] <tibbs> Why on earth should I be the one to patch it?
[12:47] <f13> all it does is clarify that buildroot needs to be removed.
[12:47] <thimm> tibbs: because you articulated the demand for it ;)
[12:47] <spot> f13: we're documenting the de facto standard
[12:47] <f13> but doesn't actually solve the problem that was brought up.
[12:47] <thimm> f13: true, the race remains
[12:47] <tibbs> thimm: That's complete idiocy.
[12:47] <f13> spot: right, I'm all for that.
[12:47] <spot> f13: two problems, undocumented defacto standard, race condition
[12:47] <f13> gotcha.
[12:48] <scop> +½, I think the "This is to ensure" part needs rewording (no better suggestions right now though)
[12:48] <f13> +1 to clarifying the standard.
[12:48] <spot> i want to at least get the first if we can't agree on how to do the second
[12:48] <lutter> +1
[12:48] <spot> tibbs: you, someone else, someone not me.
[12:48] <f13> tibbs: welcome to opensource :/ Oft times the only way to get results is to do the work yourself and provide a patch. Otherwise it just sits in the work queue and will be gotten to, whenever.
[12:49] <spot> everytime i try to fix rpm, i get covered in animal waste. not volunteering to do that ever again.
[12:49] <tibbs> Now we have devolved to idiocy if this committee can't even freely discuss the proper place to fix real problems without one of us being told to go away and patch it.
[12:49] <spot> we dont have mandate over what rpm does in this committee
[12:49] <thimm> tibbs: On every second issue you cry "it's rpms' fault"
[12:49] <spot> we only have mandate over what rpm SPECS do
[12:50] <tibbs> thimm: back it up or be quiet.
[12:50] <thimm> tibbs: rpms is the tools we have with the bugs/features its has
[12:50] <spot> if rpm makes any of our SPEC guidelines moot, awesome.
[12:50] <spot> but we can't just close our eyes and hope rpm is going to fix these issues
[12:50] --> Southern_Gentlem has joined this channel (n=notfred@unaffiliated/Southern-Gentlem).
[12:50] <spot> because history shows very clearly that rpm doesn't fix most of its issues.
[12:50] <f13> indeed.
[12:50] --> GrapeApe has joined this channel (n=dhardiso@208.7.216.8).
[12:50] <spot> if the workarounds in spec files are non-intrusive, then we do them.
[12:50] <f13> we have all of what, one person ? maybe 3 doing rpm work?
[12:51] <spot> when they stop being needed, we drop them happily.
[12:51] <f13> or rather rpm work that we'd like to consume
[12:51] <GrapeApe> Hello all.
[12:51] <thimm> anyway, the first part of tom's sugestion passes
[12:51] <thimm> What about the race?
[12:51] <spot> lets argue about the race on the mailing list
[12:51] <-- GrapeApe has left this channel ("Sorry to interrupt.").
[12:51] <spot> try to come up with some good ways to solve it
[12:52] <spot> Next item: http://fedoraproject.org/wiki/PackagingDrafts/RubyGems
[12:52] <thimm> I think the proposed one was as KISS as it could get
[12:52] <thimm> Anything else has no chance IMHO
[12:52] <scop> thimm, come on, that's not a very constructive mindset
[12:52] <spot> the only thing that concerns me about the RubyGems guideline is the pre-built binary content
[12:52] <lutter> spot: what do you mean with 'pre-built' ?
[12:53] <thimm> scop: OK, I'll be glda to be rpoven wrong, really!
[12:53] <spot> lutter: am i confused in thinking that the gems come with binaries in them in some cases?
[12:53] <spot> architecture specific binaries?
[12:53] <lutter> spot: you are :) They should come with source like any good old tarball
[12:54] <thimm> Why of us speaks ruby (other than lutter)?
[12:54] <spot> ok, so everything that is arch specific gets built from source? :)
[12:54] <lutter> spot: if the gem is e.g. a db driver, it should contain a bunch of c files that 'gem install' will compile into a DSO
[12:54] <spot> lutter: ahhh, ok. :)
[12:54] <tibbs> Yes, everything gets build from source.
[12:54] <thimm> s/Why/Who/
[12:54] <tibbs> It's just another language-specific packaging system to work around.
[12:54] <spot> then i'm ok with the draft.
[12:54] <lutter> spot: there should be no change to what's allowed in a source rpm (just that instead of a tarball you have a sligthly different archive, a gem)
[12:54] <spot> I assume something actually provides "rubygems"
[12:55] <scop> lutter, why Provides: rubygem(%{gemname})?
[12:55] <tibbs> I have a concern about the naming of these packages.
[12:55] <lutter> spot: it's cleverly called 'rubygems' ;)
[12:55] <thimm> tibbs++
[12:55] <tibbs> would ruby-gems-blah be better than "rubygems-blah"?
[12:55] <scop> s/gems/gem/
[12:55] <thimm> Or ruby-blah?
[12:55] <tibbs> We already have php-pear-*
[12:56] <lutter> tibbs: it should be 'rubygem-foo' (no plural)
[12:56] <thimm> We don't call python-egg-blah because it was build by a python egg
[12:56] <lutter> it's what Suse uses, too, and I figured there's no reason to deviate from that for no obvious reason
[12:56] <spot> thimm: yeah, nor do we call things foo-tar
[12:56] <tibbs> We do have php-pear-* and php-pecl-* out of fear that shorter names might conflict.
[12:57] <spot> gem is just the upstream packaging though
[12:57] <thimm> tibbs: I always wondered why
[12:57] <tibbs> I have no idea if that fear extends to ruby-* and ruby-gem-*
[12:57] <lutter> and it's entirely possible that the same thing is packaged both 'straightup' and as a gem (e.g. ruby-sqlite and rubygem-sqlite)
[12:57] <thimm> But it's the same content, right?
[12:57] <spot> lutter: but would they be different end results?
[12:57] <tibbs> Would we actually want to package both in that situation?
[12:57] <-- Southern_Gentlem has left this channel ("Leaving").
[12:58] <lutter> spot: yes, since only the rubygem-sqlite would make gem's dependency system happy when you try to install sth that needs a sqlite gem
[12:58] <lutter> OTOH, ruby-sqlite (which exists) doesn't pull in all kinds of other stuff that rubygems needs
[12:58] <spot> lutter: does rubgem-sqlite conflict with ruby-sqlite ?
[12:58] <thimm> But what if I need to pull in ruby-sqlite
[12:58] <tibbs> My understanding of python indicates that its internal egg dependency system would have the same issue.
[12:58] <thimm> Why do I need to know whether it was an egg or not
[12:59] <thimm> I just want Requires: ruby-foo
[12:59] <thimm> And not toggle my dependencies on how foo was packaged
[12:59] <lutter> basically the 'rubygem-' prefix should tell people that this package doesn't just provide library foo, but that it is also packaged in a way that gem is happy about it and that they can install their own stuff that requires a foo gem on top of that with gem
[12:59] <abadger1999> tibbs: Yes but we can build the egg meta-info from the tarball.
[12:59] <scop> can the gem metadata be packaged separately, and have it require and use the non-gem package?
[13:00] <thimm> do we *need* the gem metadata ... ?
[13:00] <tibbs> abadger1999: Right, which is why it doesn't need an "-egg-" bit in the package name.
[13:00] <lutter> scop: not really .. for a lot of gems the build process is pretty intertwined with gem, and gem does some gymnastics behind the scenes when libraries are loaded etc.
[13:00] <spot> or, alternately, all ruby-* files need to include gem metadata
[13:00] <tibbs> thimm: I think we need it for the same reasons python needs the egg stuff.
[13:00] <thimm> But python does not need an other naming
[13:00] <abadger1999> Exactly. So I guess the question is -- will we ever package the non-gem version of a ruby module to install in parallel with the gem version.
[13:01] <tibbs> thimm: I think you see my point.
[13:01] <spot> abadger1999: i don't think so, given the obvious file conflicts
[13:01] <lutter> thimm: there's a difference in how you include a gem from your ruby code vs. a directly packaged lib
[13:01] <thimm> So, if it work with python, why not with ruby?
[13:01] <f13> eeew.
[13:01] <scop> I'm pretty sure this won't be resolved tonight, so if you don't mind, I'd like to ask for quick comments on perl(ExtUtils::MakeMaker) as a build dep
[13:01] <scop> http://www.redhat.com/archives/fedora-packaging/2007-March/msg00028.html
[13:01] <f13> I really don't want to see two packages providing the same thing, just packaged and layed out differently
[13:01] <tibbs> f13: +1
[13:02] <scop> f13++
[13:02] <thimm> f13+=1000
[13:02] <lutter> f13: it makes a difference on how you use them
[13:02] <spot> f13++
[13:02] <tibbs> scop: Does that build dep actually solve the primary issue?
[13:02] <lutter> f13: what do you suggest then that would let us have rails packaged in any amount of reasonable timeframe ?
[13:03] <tibbs> If so I think it's a fine idea, but we shouldn't try to push things into guidelines until the whole perl-devel thing.
[13:03] <spot> lutter: how about "if it comes as a gem, package it as a gem, if not, don't."
[13:03] <scop> tibbs, I don't see why it wouldn't be correct, no matter what
[13:03] <tibbs> lutter: We only have a few existing ruby packages we might have to reconsider.
[13:03] <spot> then document how to package it as a gem
[13:03] <lutter> spot: sure
[13:03] <spot> and drop the "gem" in the naming
[13:04] <spot> ruby-whatever
[13:04] <thimm> spot:+1
[13:04] <scop> tibbs, and it's not for the guidelines, it's for the perl spec template
[13:04] <abadger1999> scop: The perl change looks good.
[13:04] <thimm> scop: Propose a vote?
[13:04] <thimm> +1
[13:04] <spot> +1
[13:04] <lutter> spot: no ... because it's an important distinction
[13:04] <scop> +1 obviously, sure go ahead and vote
[13:05] <lutter> spot: why is it ok to have php-pear and php-pecl and rubygem is such a big deal ?
[13:05] <tibbs> +1 for BuildRequires: perl(ExtUtils::MakeMaker) in the perl template.
[13:05] <spot> because pear/pecl are different types of files
[13:05] <abadger1999> +1 for perl
[13:05] <spot> gem is just wrapper.
[13:05] <racor> +1 for perl(ExtUtils::MakeMaker) in perl spec template
[13:05] <thimm> perl passes with 5+1
[13:05] <spot> its very likely that we'd have php-pecl-foo and php-pear-foo and have them be totally different bits
[13:05] <lutter> spot: it's more than that .. it also dictates where files wind up on install etc.
[13:06] <spot> lutter: but unlike php, they're the same files
[13:06] <spot> you can be creative with symlinks if you want to cover both locations
[13:06] <lutter> spot: but will be in different locations in the fs
[13:06] <thimm> lutter: there are different install locations?
[13:06] <thimm> that's bad
[13:06] <thimm> can't we fix that?
[13:06] <abadger1999> lutter: When I access them from a ruby script, do I use the same syntax to import/require/include the module whether it's a gem or not?
[13:07] <lutter> abadger1999: no
[13:07] <f13> gak
[13:07] <tibbs> f13: Yes, ruby has a lot to learn.
[13:07] <thimm> gems seems like no real advatnage then
[13:07] <lutter> abadger1999: for a 'normal' ruby lib you say 'require "foo"', for a gem you say 'require "rubygems"; gem "foo"'
[13:08] <abadger1999> "Explicit is better than implicit" :-)
[13:08] <tibbs> It seems like having "gem" in the name is pretty much unavoidable.
[13:08] <lutter> thimm: it's what the mahjority of ruby packages uses .. believe me, I tyried to package rails as a non-gem, but upstream makes that pretty hard, sicne they all work under the assumption that everybody uses gem
[13:08] <thimm> Can every gem be rpm-packaged as no-gem?
[13:08] <spot> ok, then i'd say that everything that can be a gem, should be a gem. if its a gem, it can be ruby-gem-foo
[13:08] <tibbs> I would be happy with ruby-gem-*
[13:08] <spot> if it can't be a gem, then it can be ruby-foo
[13:08] <spot> but if ever that package can be a gem, then ruby-foo goes away and ruby-gem-foo takes its place
[13:09] <lutter> thimm: that's what I just tried to say with teh rails example .. you wind up spending way too much time to package as a non-gem
[13:09] <spot> never ever ever are ruby-foo and ruby-gem-foo permissable
[13:09] <thimm> spot: and breaks all dependent packages?
[13:09] <abadger1999> lutter: Can ruby-gem-foo and ruby-foo be parallel installed?
[13:09] <lutter> spot: we only have a handful of ruby- packages, and I don't see people rushing in to package more
[13:09] <lutter> abadger1999: yes
[13:09] <spot> thimm: it seems, to fix the dependent packages, is a two line change.
[13:09] <thimm> spot: if a package suddenly changes form gem to non-gem or vice verse all dependent packages goo fubar
[13:09] <spot> 'require "foo"' vs 'require "rubygems"; gem "foo"'
[13:10] <scop> plus the dependency baggage (?) the gem system brings in?
[13:10] <lutter> thimm: I would bet that we'll never see upstream going from gem to non-gem
[13:11] <thimm> Mabye we need a ruby policy officer (lutter ;) to watch over the ruby packages in Fedora?
[13:11] <racor> lutter: AFAIU, gems to me seems to be a configuration-implementation detail. All that matter to us should be consistency within the distro, not the "how".
[13:11] <abadger1999> spot: Are you still against ruby-gem-foo and ruby-foo both existing (if they can be parallel installed)
[13:11] <spot> abadger1999: yes, i think that could almost certainly be handled with symlinks
[13:11] <lutter> scop: that's a good concern to raise with teh upstream gem guys .. I am not very happuy with lots of aspects of gems, but that's what most people use, and it's the simplest way to get many ruby things into fedora
[13:11] <thimm> Maybe call the always ruby-foo and have virtual provides for gem?
[13:13] <spot> lutter: is it possible for Fedora to make gems for things that aren't in gems?
[13:13] <abadger1999> spot: I'm not sure we want to go down that path....
[13:13] <lutter> spot: if somebody wants to invest the time; somebody needs to write the 'gem spec'
[13:14] <abadger1999> I have experience with python eggs and the TurbGears stack which is somewhat painful in that regard.
[13:14] <spot> abadger1999: ok...
[13:14] <lutter> spot: but I wouldn't want deviating from upstreams preferred way to distribute stuff mandatory to include sth in Fedora
[13:14] <lutter> spot: it's like saying we'll only include your C library if it's been autoconfiscated
[13:14] <spot> the parallel install thing is the pressing issue as far as I'm concerned
[13:15] <spot> but strictly speaking, if they don't conflict, its not a guidelines violation
[13:16] <racor> lutter: No, as I understand you, would want parallel installation of conflicting sets of packages.
[13:16] <f13> somebody ought to shoot upstream for creating this shitspace.
[13:16] <lutter> spot: and it's an improvement over what most people do today (yum install rubygems && gem install rails)
[13:16] <lutter> f13: go right ahead
[13:16] <spot> ok, then i'm fine with rubygem-foo
[13:16] <racor> lutter: And? what prevents you to do it differently?
[13:16] <tibbs> ruby-gem-* or rubygem-*
[13:17] <tibbs> ?
[13:17] <spot> tibbs: whichever makes people happy.
[13:17] <scop> ruby-gem-*++
[13:17] *** pyxel is now known as marek.
[13:17] <abadger1999> I think ruby-gem-* follows the php-* precedent.
[13:17] <spot> ruby-gem-* is fine by me
[13:17] <lutter> tibbs: as I said rubygem-* is what suse uses, and I don't see why we need to haev a grtuitous difference there
[13:18] <lutter> racor: don't know what you mean
[13:18] <tibbs> I see consistency within our distro as more important than consistency with other dstros, but it's not a huge deal either way.
[13:18] <racor> lutter: replace a non-gem'ed set of packages with a gem'ed one. Who should care?
[13:18] <scop> what about other distros? Mandriva? Debian and friends?
[13:18] * rdieter is ok with either naming scheme.
[13:18] <lutter> tibbs: but if there's an overwhelming preference for ruby-gem, I'll be fine with that and change gem2spec (again)
[13:19] <lutter> scop: no idea
[13:19] <lutter> racor: teh package that uses the non-gem'd library will break
[13:20] <spot> gentoo uses rubygem
[13:20] <lutter> is there any way we can vote on this ?
[13:21] <spot> debian doesn't permit gem packaging
[13:21] <tibbs> Is there anyone who would vote against the proposal as it but would vote for it if the naming were changed?
[13:21] <spot> +1 for the proposal
[13:21] <scop> Mandriva doesn't appear to have any gems packaged either
[13:22] <lutter> +1 (obviously)
[13:22] <abadger1999> ~ I would like to look at a gem and non-gem package first.
[13:22] <spot> abadger1999: http://pkg-ruby-extras.alioth.debian.org/rubygems.html
[13:22] <lutter> abadger1999: have a look at my p.r.c page .. there's quite a few examples
[13:22] <rdieter> +1
[13:22] <spot> has file listings from what a gem vs non-gem look like on install
[13:22] <abadger1999> I was looking at http://rubyforge.org/frs/?group_id=254&release_id=9438
[13:22] <abadger1999> ruby-sqlite
[13:23] <abadger1999> lutter: Is that people.redhat.com/home/lutter?
[13:24] <scop> 0 if we're voting now, only a subset of the draft has been discussed
[13:24] <lutter> abadger1999: misleading IRC nick ;) http://people.redhat.com/dlutter/yum/
[13:24] <abadger1999> Thanks.
[13:26] <tibbs> Some questions about gems and %doc:
[13:26] <tibbs> Does gem2spec mark documentation as such?
[13:26] <tibbs> Do gems work without the documentation present?
[13:27] <thimm> "gems incompatible to FHS"???
[13:27] <rdieter> In short, if they don't work without the docs present, they shouldn't be makred %doc. :)
[13:28] <tibbs> Well, that's one obvious conclusion.
[13:28] <rdieter> it's getting late, gotta run soon, anything else?
[13:28] <racor> 0, I fail to understand the rationale applied in here, but also don't understand enough about ruby
[13:28] <lutter> tibbs: yes, gem2spec marks docs as %doc (as long as they are amrked as docs in the gem spec)
[13:28] <lutter> tibbs: yes, they work w/o the docs present
[13:28] <tibbs> Is there some internal ruby documentation browser?
[13:29] <lutter> thimm: I would look at the debian position as somehwat extreme
[13:29] <thimm> Is it FHS compliant?
[13:29] <lutter> tibbs: yes, looks sth like http://www.ruby-doc.org/core/
[13:29] <abadger1999> lutter: Does a gem have to be untarred to work or can it be installed as a single file?
[13:30] <thimm> BTw Debain/Ubuntu seem to have rails w/o gems ...
[13:30] <lutter> abadger1999: 'gem install' untars it and also keeps the archive around
[13:30] <tibbs> Do the documentation at least needs to stay with the rest of the package for the tools to work, but a nodoc install doesn't actually break anything.
[13:30] <lutter> thimm: debian's complaint about non-FHS is that gems install into one tree (/usr/lib/ruby/gems/1.8 by default) with docs and all
[13:30] <thimm> lutter: You said that it is difficult to do rails w/o gem, how did Debian/Ubuntu manage?
[13:31] <abadger1999> Must it? I ask because python eggs as distributed by upstream are meant to run from the egg, not untarred.
[13:31] <lutter> thimm: I don't know .. they are either smarter or have more time than me
[13:31] <thimm> Well, maybe their packages can just be inspected and learned from.
[13:31] <lutter> tibbs: a nodoc install would break only the doc-related funcionality
[13:31] <abadger1999> This is either "better" or a sneaky way to get around FHS complaints depending on your viewpoint.
[13:31] <thimm> I really don't want to see FHS ciolation behind our backs
[13:32] <tibbs> I think it would be inconsistent to allow the python egg stuff without complaint and then ban gems.
[13:32] <thimm> eggs don't violate FHS
[13:32] <lutter> thimm: what exactly does this violate about hte FHS ?
[13:32] <spot> well, this doesn't seem to have momentum to pass, we'll set it back aside and reconsider it later.
[13:32] <thimm> They could carry optional and additional metadata
[13:32] <spot> lutter: you may want to start this discussion on the mailing list.
[13:32] <lutter> spot: I did .. and got nothing but crickets
[13:33] <tibbs> Yes, he tried.
[13:33] <spot> well. :/
[13:33] <lutter> thimm: is you tell me what exactly about hte FHS gems are violating, we can talk about fixing that .. but a blanket statement of "this is in violation of the FHS" doesn't help anybody
[13:33] <spot> this meeting is done for this week. we'll argue about it next week i suppose.
[13:34] <lutter> s/is/if/
[13:34] <tibbs> Perhaps the meeting summary will generate more discussion. I'll make a point it.
[13:34] <thimm> lutter:
[13:34] <thimm> /usr/lib/ruby/gems/1.8/doc/rmail-0.17/rdoc/rdoc-style.css
[13:34] <thimm> /usr/lib/ruby/gems/1.8/gems/rmail-0.17/lib/rmail/parser/pushbackreader.rb
[13:34] <thimm> don't look like FHS
[13:35] <lutter> thimm: look, I am not that big a fan of gems, but it's the prevalent packaging mechanism for ruby, I don't think it actually harms anything from a distro point of view, and without teh possibility to package ruby gems, we'll be pure and leave people to install gems outside of rpm
[13:35] *** spot sets the channel topic to "http://fedoraproject.org/wiki/Communicate/FedoraMeetingChannel -- Meetings often get logged".
[13:35] <thimm> Aynway to be fair: I know close to nothing about ruby, so I would vote neither +1/-1
[13:36] <thimm> lutter: CPAN is the preferred packaging mechanism for perl, too and it's banned from Fedora
[13:36] <lutter> thimm: the only thing that gems do that otehr languages don't do (e.g. python or perl) is having api docs in the gemdir
[13:37] <tibbs> It's far from banned.
[13:37] <lutter> (those aren't system docs, they are api docs)
[13:37] <tibbs> We even ship the package.
[13:37] <thimm> We also ship /usr/local
[13:37] <lutter> and I don't read the FHS as saying that all docs whatsoever need to be in /usr/share/doc
[13:37] <tibbs> It's just not the recommended way for installing Perl modules.
[13:37] <tibbs> The same applies for PEAR.
[13:38] <tibbs> And eggs, I suppose.
[13:38] <lutter> thimm: I am not familiar with perl apckaging, but I thought our perl packages were basically just cleverly wrapped cpan
[13:38] <rdieter> any optinions on: wordtrans merge review: http://bugzilla.redhat.com/226543
[13:38] <thimm> No, not at all
[13:39] <thimm> There is no cpan-packaged package in Fedora.
[13:39] <rdieter> currently uses: Version: 1.1pre13 how best to address that (if at all?)
[13:39] <tibbs> There's not really any such thing as a "cpan-packaged" package.
[13:39] <thimm> And perhaps we should make sure th eguidelines prohibit any CPAN packaging
[13:39] <thimm> tibbs: %install could call cpan
[13:39] <thimm> And download all required bits, as well ...
[13:39] <tibbs> You're really strecthing now.
[13:39] <thimm> So no Source: needed ;)
[13:40] <thimm> That's why CPAN packaging is not allowed
[13:40] <tibbs> Grasping at straws. Makes it easy to ignore your argument.
[13:40] <thimm> It is not impossible, just a very bad practice
[13:40] <thimm> tibbs: What argument? That CPAN is not suited for rpm packaging?
[13:40] <tibbs> Nobody is advocating doing anything other than grabbing the upstream tarballs (or zips or whatever they use).
[13:41] <thimm> We're getting off-topic and out of time-limits
[13:42] <tibbs> rdieter: wordtrans versioning is horrible.
[13:42] <thimm> bye all!
[13:42] <lutter> thimm: teh essential problem is this: the ruby community has a clear preference for how they want to package stuff, and that's the expectation of every ruby programmer out there ... do we as the Fedora community enable those ruby programmers, if it doesn't really cause any problems or do we want to wait for another couple of years until maybe they get a little closer to our needs ?
[13:42] <tibbs> lutter: You won't convince him that way.
[13:43] <lutter> tibbs: probably not
[13:43] <thimm> lutter: It seems that it's possible to have both the distro's parameters fulfilled and rails imported, why not check the competition's solution?
[13:44] <thimm> But I really need to bail out, now, see you next week!
[13:44] <lutter> thimm: as I said, I tried and gave up after spending way too much time on it ... I can package a gem in under ten minutes or spend an hour or two trying to reverse engineer what needs to be done for a non-gem install
[13:50] <-- scop has left this channel ("Leaving").
[13:56] <abadger1999> lutter: I think we have to press rubygems upstream to come into FHS compliance.
[13:56] <abadger1999> In the interim, probably we want to include gems in the distro.
[13:57] <abadger1999> But I have to look at some of these packages this week to see.
[13:58] <lutter> abadger1999: obviously, I agree with the latter; but I am not even sure what making them FHS compliant would mean, since for most of the things gems do there is precedent from other packages
[13:58] <lutter> abadger1999: yeah, that would be nice .. let me know what you think