Packaging:Minutes20070320

Fedora Packaging Committee Meeting of {2007.03.20}

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)

Writeups

The following drafts have been accepted by FESCO and are to be written into the guidelines:

• Codifying when it is safe for scriptlets to write to various directories: PackagingDraft/ScriptletsWriteDirs
• Prepping BuildRoot for %install: PackagingDrafts/BuildRootHandling

Votes

The following proposals were considered:

• In a bit of bookkeeping, the old question of whether the PC should mandate ipv6 support was considered.
• Rejected; the committee feels this is a policy issue
• Voting for: rdieter f13 spot thimm lutter tibbs abadger1999
• Voting against: (none)

• Addressing another longstanding question, the committee took up the issue of making the Group: tag optional in specfiles.
• The core RPM maintainer doesn't wish to take the patch making the tag optional at this time.
• Rejected; the committee may revisit this post-F7.
• Voting for rejection: spot f13 thimm rdieter scop abadger1999 racor tibbs lutter
• Voting against rejection: (none)
• The Group: tag is still nearly meaningless, and packagers are free to put whatever they feel is best there.

• Guidelines for using cmake: PackagingDrafts/cmake
• Accepted.
• Voting for: f13 rdieter spot thimm abadger1999 lutter scop tibbs
• Voting against: (none)
• Abstentions: racor ("+0")
• Some of what is required to get cmake to work properly with 64-bit systems and so the proposed macros are a bit nasty, but currently no cleaner solution has presented itself. Since these macros will live in the cmake package, they are easily adapted as cmake evolves.

Other Discussions

The following additional items were discussed; see the logs for full details.

• Cleanups were done to Packaging/Committee and various other packaging-related pages; these are ongoing. In particular, it's been made clear that anyone is free to write up and contribute a draft for consideration by the committee.

• Guidelines for packaging Ruby Gems: PackagingDrafts/RubyGems . Some progress was made here, but the fundamental question of whether Gems should be allowed into Fedora at all is seen by some as a policy issue, not a packaging one, and thus may need to be escalated to FESCo. Others disagreee; of course, FESCo is free to comment in any case, as is anyone else who wishes to.

IRC Logs

Note that discussion of the Ruby Gems issue (again) continued beyond the end of the meeting; the entire log has been included.

[12:01]  <thimm> FPC ping
[12:02]  <abadger1999> Packaging Meeting?
[12:02]  <thimm> abadget1999: yes
[12:03]  <lutter> I am here
[12:03]  <abadger1999> spot, f13, racor, rdieter, tibbs: meeting?
[12:04]  <f13> here.
[12:04]  <tibbs> Yep.
[12:04]  * spot is here
[12:04]  <spot> here
[12:05]  <f13> *cough*
[12:05]  <racor> here
[12:06]  *** abadger1999 sets the channel topic to "Fedora Packaging Meeting -- Tuesdays @ 17:00 UTC".
[12:06]  <thimm> 1st topic: Accept commitment to address EPEL related topics
[12:06]  <thimm> +1
[12:06]  <tibbs> OK, so is thimm running the meetings now?
[12:06]  <spot> thimm: i don't even think we need to vote on that
[12:06]  <spot> and no, i am. :)
[12:06]  <thimm> tibbs: no, I just wanted to start it up ;)
[12:06]  <spot> Alright, lets get started
[12:07]  <spot> item 1: Packaging/Committee
[12:07]  <f13> woo!
[12:07]  <f13> +1 for it
[12:07]  <thimm> ?
[12:07]  <spot> I reworked the page which describes who we are, what we do, where we discuss things, and how Drafts become Guidelines
[12:07]  <spot> http://fedoraproject.org/wiki/Packaging/Committee
[12:07]  <spot> You should all read it, and if you disagree, let me know.
[12:08]  <f13> how wthe lonly bill gets up capital hill.
[12:08]  <spot> Didn't really change anything. Just clarified it.
[12:08]  <-- c4chris__ has left this server (Read error: 110 (Connection timed out)).
[12:08]  <abadger1999> spot: +1
[12:08]  <lutter> I thought it's one of those things where you don't want to know how it's made
[12:08]  <spot> I did break up the GuidelinesTodo page into two sections
[12:08]  --> c4chris__ has joined this channel (n=chris@147-183.1-85.cust.bluewin.ch).
[12:08]  <spot> there is now a PackagingDrafts/DraftsTodo page
[12:08]  <thimm> Nice work!
[12:09]  <spot> this is so that anything with cvs access can add a draft and have it show up on GuidelinesTodo for us to consider
[12:09]  <spot> s/anything/anyone
[12:09]  <spot> (i suppose intelligent perl AI might be adding drafts someday, but i digress)
[12:09]  <abadger1999> spot: Since you mention Fedora Contributors in Step1, maybe we want to add a little bit that says they can continue to push things forward/be a part of discussion in Step 2.
[12:10]  <spot> abadger1999: thats a good point.
[12:10]  --> scop has joined this channel (n=scop@cs27014175.pp.htv.fi).
[12:10]  <lutter> spot: and mention in step one that they can/should email fedora-packaging
[12:10]  <spot> the other point of interest with regards to that is that things will need to be in a draft to be considered.
[12:10]  <scop> hello, sorry I'm late
[12:10]  <f13> Can we get rid of http://fedoraproject.org/wiki/PackagingDrafts as a page itself?
[12:10]  <spot> lutter: +1
[12:11]  <thimm> spot: Packaging Guidelines are mentioned a couple time, but never linked to, maybe nice to have the first mention of it link to Packaging/Guidelines
[12:11]  <spot> thimm: ok. :)
[12:11]  <spot> scop: <spot> I reworked the page which describes who we are, what we do, where we discuss things, and how Drafts become Guidelines
[12:11]  <spot> <spot> http://fedoraproject.org/wiki/Packaging/Committee
[12:11]  <rdieter> afk 2 (more) minutes.
[12:12]  <spot> scop: please read it and suggest changes/improvements
[12:12]  <scop> will do, looks good on first sight
[12:12]  <spot> OK, next item of business
[12:13]  <f13> spot: since we have a DraftTodo, can we get rid of http://fedoraproject.org/wiki/PackagingDrafts ?  It isn't automatically updated, and doesn't show up in the process
[12:13]  <spot> f13: yeah.
[12:13]  <spot> i'll make it redirect to DraftsTodo
[12:13]  <f13> huzzah
[12:14]  <spot> Next item: The Fedora Board says that we are responsible for all packaging related issues for Fedora projects.
[12:14]  <spot> This includes EPEL.
[12:14]  <spot> Does anyone here have any concerns with this?
[12:14]  <f13> not really
[12:14]  * rdieter is back (sorry).
[12:14]  <rdieter> no prob.
[12:14]  <scop> how many of us actually actively use EL?
[12:14]  <f13> since EPEL should follow the RHEL packaging guidelines, and RHEL uses the FEdora packaging guidelines
[12:15]  <lutter> makes sense
[12:15]  <tibbs> I have some centos around.
[12:15]  <f13> scop: I do.
[12:15]  <thimm> I, too
[12:15]  <scop> I do too, just sanity checking
[12:15]  * spot will have at least one or two RHEL boxes dedicated to EPEL.
[12:15]  <racor> I don't
[12:15]  <abadger1999> Only a tiny bit.
[12:16]  <scop> I'm pretty sure rdieter does
[12:16]  <spot> OK, next item:
[12:16]  <rdieter> I use EL4 too
[12:17]  <spot> there are two items in Action Items on GuidelinesTodo marked as followup
[12:17]  <spot> ipv6 in Fedora
[12:17]  <spot> and
[12:17]  <spot> RPMGroups
[12:17]  <spot> on ipv6 in Fedora, i think this is more appropriate for a SIG and not for FPC
[12:18]  <spot> I'd like to move that to Rejected
[12:18]  <spot> and let any interested ipv6 parties do their own stuff
[12:18]  <scop> worksforme
[12:18]  <thimm> rejected sounds harsh
[12:18]  <spot> thimm: we can reword the page, i just need to put it in the "considered, but not in guidelines" section
[12:19]  <thimm> Well, it can go under rejected with a not that it's not under the FPC mandate to judge on ipv6
[12:19]  <spot> thimm: *nod*
[12:19]  <thimm> s/not/note/
[12:19]  <rdieter> spot: +1, sounds reasonable.
[12:19]  <f13> +1
[12:19]  <racor> +1
[12:19]  <spot> +1
[12:19]  <thimm> +1
[12:19]  <lutter> +1
[12:19]  <tibbs> +1
[12:19]  <abadger1999> =1
[12:19]  <abadger1999> s/=/+
[12:20]  <spot> ok. thats a pass.
[12:20]  <spot> the other item is RPMGroups
[12:20]  <spot> Paul (Fedora RPM maintainer) doesn't want to take that patch at this time.
[12:20]  <f13> Is this the "we don't care what you put in there, we're going to ignore it?"
[12:20]  <thimm> For F7 it's too late anyway
[12:20]  <f13> thimm: there is still a couple hours until the feature freeze (:
[12:20]  <thimm> :)
[12:20]  <spot> i'd like to drop it to rejected, and we can revisit it in the future.
[12:21]  <thimm> OK
[12:21]  <spot> Paul said that he'll be more open to drastic RPM changes post F7
[12:21]  <spot> so, we'll see.
[12:21]  <f13> ok
[12:21]  <thimm> Vote?
[12:21]  <spot> +1
[12:21]  <f13> +1 from me
[12:21]  <thimm> +1
[12:21]  <rdieter> +1 (I see no better alternative)
[12:21]  <scop> +1
[12:21]  <abadger1999> There's no way to push forward without rpm buy in so +1
[12:21]  <racor> +1
[12:21]  <tibbs> +1
[12:22]  <lutter> +1
[12:22]  <spot> ok. Next item: writeup action items
[12:22]  <tibbs> But then what should actually go into the Group: tag?
[12:22]  <spot> tibbs: anything. whatever.
[12:22]  <spot> don't care.
[12:22]  <scop> "appease rpmlint" :)
[12:22]  <tibbs> I think there's actually an existing guideline, though.
[12:22]  <spot> tibbs: is there?
[12:23]  * spot doesn't remember writing one, but there might be one
[12:23]  <tibbs> There used to be a list somewhere.
[12:23]  <thimm> The guidelines mention Group: documentation
[12:23]  <scop> 'twas more or less /usr/share/doc/rpm-*/GROUPS IIRC
[12:23]  <lutter> if there is we should just drop it
[12:23]  <spot> scop: i think so.
[12:24]  <spot> the only mention of Group in the Guidelines is for documentation subpackages
[12:24]  <spot> and thats a recommendation
[12:24]  <tibbs> It's just http://fedoraproject.org/wiki/RPMGroups
[12:25]  <spot> ok
[12:25]  <thimm> Kill it?
[12:25]  <thimm> (the wiki page)
[12:25]  <tibbs> I'd think so.
[12:25]  <spot> yeah. kill it.
[12:26]  <rdieter> die die die.
[12:26]  <spot> ok. writeup action items
[12:26]  <tibbs> OK, it's gone.
[12:26]  <spot> two of them are mine, one is racor's
[12:26]  <spot> one is f13's
[12:26]  <thimm> I vote that you write them up! ;)
[12:26]  <spot> i'll try to do mine tonight
[12:26]  <spot> racor: do you need help writing yours up?
[12:27]  <racor> mine probably should have been closed -.I added it to the wiki some weeks ago
[12:27]  <spot> ok, i thought that was the case.
[12:27]  <tibbs> Yes, I think it's already been done.
[12:27]  <rdieter> racor: you could have said:    ok.... done.  (wow, was that fast or what?). :)
[12:27]  <f13> what one do I have left?
[12:27]  <spot> f13: Init scripts
[12:28]  <f13> hrm, I wrote that up, and I thought I moved it to the done section.
[12:28]  <f13> whoops.
[12:28]  <spot> alright new drafts time
[12:28]  <spot> lets start with cmake
[12:28]  <spot> http://fedoraproject.org/wiki/PackagingDrafts/cmake
[12:28]  <rdieter> folks may need to be careful editing PackagingTodo, I've noticed trying to edit it from time to time that I almost overlooked the warning about it being edited by someone else.
[12:28]  <lutter> spot: we still have the unfinished rubygems biz from last time
[12:29]  <spot> lutter: i know.
[12:29]  <spot> the cmake guidelines seem ok to me. they add some convenience.
[12:30]  <scop> two small things
[12:30]  <tibbs> We definitely need something about cmake, unless we're OK with folks just doing whatever.
[12:30]  <thimm> Too many submacros that become API Visible
[12:30]  <scop> people noted that many cmake builds should be done out-of-source-tree after all
[12:30]  <thimm> Can't we just have %cmake?
[12:30]  <rdieter> can one do api-invisible macros?
[12:30]  <tibbs> I'm not sure what "API Visible" means in this context.
[12:31]  <thimm> rdieter: Yes, by not making them :)
[12:31]  <rdieter> scop: the cmake macro doesn't affect in or out of tree builds.
[12:31]  <thimm> It means that there will be _cmake_lib_suffix64 left over
[12:31]  <thimm> that can be changed by the user
[12:31]  <thimm> in probably abusinve ways
[12:31]  <rdieter> one can as easily: mkdir build-local; %cmake ..
[12:31]  <rdieter> oops: mkdir build-local; cd build-local; %cmake ..
[12:32]  <scop> rdieter, yes, there's the "rpm/specfile usage" recipe in the draft
[12:32]  <scop> ah, there's also a note about it
[12:32]  <spot> rdieter: would likely be good to have an "intree" and "outtree" example
[12:32]  <rdieter> spot: makes sense to add an outtree example, sure.
[12:33]  <spot> scop: what was the other small thing?
[12:33]  <thimm> rdieter: are you opposed to merging in the submacros?
[12:33]  <scop> about macroization
[12:33]  <rdieter> thimm: ??
[12:34]  <scop> if others are kept, the cmake command should also be made into one instead of hardcoding %{_bindir}/cmake IMO
[12:34]  <thimm> Eliminate for example _cmake_lib_suffix64 by inseting it into the cmake macro
[12:34]  <rdieter> thimm: ok, I don't care, either works.
[12:35]  <tibbs> I don't see how having _cmake_lib_suffix64 permits any worse hackery than any of the other macros RPM exports, but then again I don't really see why it's necessary to make it tweakable, either.
[12:35]  <rdieter> scop: sure.
[12:35]  <thimm> tibbs: "If it's tweakable it will be tweaked."
[12:35]  <tibbs> That's not really much of an argument.
[12:35]  <thimm> tibbs: and in this case I can't imagine how it would be a benefit
[12:36]  <lutter> rdieter: will it be necessary to override some of those macros like _cmake_lib_suffix64 ? The note at the end seems to say yes
[12:36]  <thimm> tibbs: Someone will think it's anice way to pass other args to cmake
[12:36]  <spot> thimm: they could always redefine %{cmake}. :)
[12:36]  <rdieter> lutters: cmake is relatively new, and so are packages that use it.  *some* apps don't deal gracefully with lib_suffix64, yet.
[12:36]  <spot> if the submacro needs to be overridden, then it should be a submacro
[12:36]  <spot> if not, then, no.
[12:37]  <tibbs> I fail to see the potency of an argument that essentially says "someone could concievably do something dumb with it".
[12:37]  <tibbs> The salient question is whether it's needed or not.
[12:37]  <rdieter> I can see both sides, but I'd rather opt for giving packagers the most (easy) flexibility to start with, until cmake and its usage matures.
[12:37]  <thimm> But then removing something will not be an options anymore
[12:37]  <rdieter> this is just a first try.
[12:38]  <rdieter> it's not set in stone.
[12:38]  <tibbs> Well, the first try will get coded into a bunch of specfiles, so we should try to get it at least mostly right.
[12:38]  <spot> rdieter: it is easier to add macros later as needed than it is to remove them
[12:38]  <spot> i would say only make the lib_suffix64 a submacro
[12:38]  <spot> and pull the rest in
[12:38]  <rdieter> spot: ok.
[12:39]  <spot> we can easily make more submacros if needed
[12:39]  <spot> everyone else ok with that? :)
[12:39]  <tibbs> Fine with me.
[12:39]  <racor> rdieter: is cmake able to handle other multilibs but lib64 - If yes, then this lib _suffix64 approach lacks generality
[12:39]  * rdieter updated the draft.
[12:40]  <spot> racor: what other multilib case is there?
[12:40]  * spot is frightened
[12:40]  <thimm> OK, the EPEL is calling:
[12:40]  * rdieter isn't aware of any other multilib cases.
[12:40]  <thimm> -DCMAKE_SKIP_RPATH:BOOL=ON might be required for older cmake version (2.2.x). With recent cmake-2.4, it should not be used.
[12:40]  <f13> there is the crazy ia64 one
[12:40]  <racor> multilibs can have any arbitrary names
[12:40]  <spot> racor: in theory
[12:40]  <rdieter> thimm: I think that comment can go, we have cmake-2.4
[12:40]  <racor> ix86_64 has ../lib64
[12:40]  <thimm> Will we be on the safe side for EPEL or should be have a safety rpath removal pin?
[12:41]  <racor> spot: I can show you ca. 50 examples
[12:41]  <tibbs> In Fedora today?
[12:41]  <racor> most prominent is multilibs on sparcs
[12:41]  <racor> tibbs: no
[12:41]  <spot> racor: multilib on sparc is lib vs lib64
[12:41]  * spot knows that a bit too well
[12:41]  <racor> spot: not on solaris ;)
[12:41]  <tibbs> I would hope spot would be something of an expert with Fedora on spare.
[12:42]  * rdieter removed the reference to cmake-2.2/rpath
[12:42]  <spot> racor: if umm, we ever manage a Fedoralaris...
[12:42]  <thimm> rdieter: checked on RHEL, cmake 2.4 builds on as old as RHEL3 => we're on the safe side
[12:42]  <spot> we'll have LOTS to fix.
[12:42]  <spot> but again, it is a submacro, its not impossible to override or reassign on conditionals
[12:43]  <scop> rdieter, %__cmake %{_bindir}/cmake, %__cmake \\\ ...
[12:43]  <thimm> scop+
[12:43]  <racor> spot: there are other linuxes but Fedora, mips and sh-linuxes also have other multilibs
[12:43]  <rdieter> I hate to invoke his name here, but jbj even commented using "%if %{_lib} inside of %cmake macro was ugly, but I don't see any way around it.
[12:43]  <rdieter> scop: ok.
[12:44]  <spot> rdieter: you could arch conditionalize, but thats just as ugly, IMHO
[12:44]  <rdieter> spot: yeah, in a perfect world, %cmake would be defined next-to wherever _lib is defined.
[12:45]  * rdieter added __cmake %_bindir/cmake
[12:45]  <racor> rdieter: can't you always pass %lib instead of doing it conditionally
[12:45]  <rdieter> cacor: if you can come up with something that works, I'm all ears.
[12:46]  <racor> for cmake - pardon, no - highly non-interesting to me
[12:46]  <rdieter> :)
[12:46]  <thimm> rdieter: %ifarch x86_64 ia64 ... ?
[12:46]  <spot> %ifarch x86_64 ia64 sparc64 alpha mips64 s390x
[12:46]  <spot> ppc64
[12:46]  <rdieter> thimm: I prefer my approach, it's more general, and always works. :)
[12:47]  <spot> sparc64v
[12:47]  * abadger1999 notes he needs to leave promptly at the hour.
[12:47]  <spot> ok, lets vote on this item
[12:47]  <scop> that should really be defined and available as %{lib64archs} or something
[12:47]  <thimm> rdieter: true, let's worry about the rest when it hits us
[12:47]  <spot> scop: yeah, or %{bitsize} should exist
[12:48]  <f13> +1 from me.  It can be fine tuned over time.
[12:48]  <rdieter> +1 (obviously)
[12:48]  <spot> +1
[12:48]  <thimm> +1
[12:48]  <abadger1999> +1
[12:48]  <lutter> +1
[12:48]  <scop> +1
[12:48]  <racor> 0
[12:48]  <spot> ok, it passes
[12:48]  <tibbs> +1
[12:49]  <spot> Ok, next item is http://fedoraproject.org/wiki/PackagingDrafts/RubyGems
[12:49]  <spot> lutter: is there any changes we should know about?
[12:49]  <lutter> no, nothign ahs changed, and there was no discussion on the list
[12:49]  <spot> so, here is what I would like to do.
[12:50]  <spot> i would like to ask FESCO if they want to permit gems into Fedora
[12:50]  <spot> this is a policy decision, not packaging
[12:50]  <spot> if they OK it, we'll figure out how to package em up
[12:50]  <spot> if they don't, well, then we're off the hook.
[12:50]  <lutter> why is it a policy decision ?
[12:50]  <skvidal> how are gems different from cpan modules?
[12:50]  <skvidal> or python eggs?
[12:50]  * skvidal is sorry for interrupting the meeting, I was just curious
[12:51]  <tibbs> There is a claim that they violate the FHS.
[12:51]  <skvidal> and if you'd like I will happily go away and stfu :)
[12:51]  <abadger1999> spot: -1.  I think gems aren't much different from eggs.
[12:51]  <scop> it may result in the need to package the same thing as both gem and non-gem, no?
[12:51]  <abadger1999> scop: That is true.
[12:51]  <rdieter> scop: I got that impression, a possibilty, yes.
[12:51]  <lutter> tibbs: to be clear: Debian claims that they violate the FHS. Sop far nobody has pointed me to teh relevant sections of hte FHS they violate
[12:52]  <tibbs> I think it's theoretically possible but these days I think most everything is coded to expect to use gems.
[12:52]  <lutter> scop: I am fine with explicitly forbidding that if it makes things easier
[12:52]  <tibbs> Unfortunately the actual module import sequences differ between gems and regular modules.  But that's not our problem to fix.
[12:52]  <lutter> and I think longer term the plan is to move gems into ruby proper so that the differences go away
[12:52]  <spot> i would rather not have both gem and non-gem packages of the same bits
[12:52]  <spot> thats confusing for users
[12:53]  <scop> ditto
[12:53]  <thimm> Debian/Ubuntu managed to do lots of ruby packages W/o gems
[12:53]  <lutter> spot: it wouldn't be end-user apps anyway; it's more about libraries that otehr apps depend on
[12:53]  <spot> lutter: users/developers
[12:53]  <spot> appA needs rubygem-foo, appB needs ruby-foo
[12:54]  <lutter> yes, but that's a decision that upstream makes, not a packaging decision
[12:54]  <spot> i'd rather see both apps using the same ruby library
[12:54]  <spot> anywhere we're duplicating code we have security implications
[12:54]  <tibbs> The problem with the debian way of doing things is that it imposes additional work on the packagers.  If a hole shows up in rails then we want a fix now, not once the maintainer can re-hack everything.
[12:54]  <lutter> then we'd have to tell one of the upstreams to change their ways
[12:54]  <spot> and bugfix pain
[12:54]  <spot> lutter: or we patch the app to use what we have.
[12:55]  <rdieter> spot: in a perfect world, that makes sense, but lutter has a good point.
[12:55]  <spot> lutter: you described that as not difficult
[12:55]  <abadger1999> spot: tibbs's point would still apply to that.
[12:55]  <lutter> spot: I don't really remember saying that
[12:55]  <thimm> FAQ: 1.4 How well does RubyGems play with other packaging systems?
[12:55]  <thimm> http://docs.rubygems.org/read/chapter/14#page62
[12:56]  <lutter> spot: the whole reason why I proposed gems packaging guidelines is that I think packaging them as 'normal' rubny packages imposes way more overhead than what is needed and useful, and slows down people wanting to submit ruby packages
[12:56]  <thimm>    From Eivind Eklund: I believe this is undoable inside the required structures for most other packaging systems (based on the Filesystem Hierarchy Standard).
[12:56]  <thimm> So rubygems itself has an FAQ on not being FHS
[12:57]  <spot> the gem FHS violation is a "binary executable" in /usr/lib
[12:57]  <lutter> thimm: without any specific reference t owhat they violate
[12:57]  <abadger1999> thimm: I'd trust Debian to understand the FHS better than a random ruby hacker ;-)
[12:57]  <lutter> spot: you mean DSO's ?
[12:57]  <abadger1999> And from looking at this, I don't think Debian's got it right either.
[12:57]  <spot> lutter: not really. it gets murky when talking about ruby/python/perl

[12:58]  <thimm> lutter, abadget1999: The FAQ on rubygems violating FHS is from their own website
[12:58]  <thimm> Check the link
[12:58]  <spot> abadger1999: i agree. debian is only moving the docs.
[12:58]  <scop> lutter, if there's a need to have foo available both as gem and non-gem, would it make sense to have the non-gem package wrap around the gem, essentially being not much more than a file somewhere which says "require_gem 'foo'"?
[12:58]  <abadger1999> thimm: I saw it last night.
[12:58]  <spot> imho, gems aren't violating the FHS
[12:59]  <abadger1999> thimm: I'm saying, I don't think the guys who wrote the FAQ have an understanding of the FHS.
[12:59]  <spot> i dont think i like gems, but i'm not required to like everything.
[12:59]  <lutter> scop: hmmm ... not sure how easy that is
[12:59]  <spot> the real key point for me is, do we let gem and non-gem packages in at the same time.
[12:59]  <spot> (of the same library)
[13:00]  <lutter> scop: the issue is that you need to make sure you avoid circularity. For lib 'foo' pacakged as non-gem, you say "require 'foo'" in code that uses it. When it's packaged as a gem, you have to say 'require "rubygems"; require "foo"'
[13:00]  <thimm> spot: is there an example?
[13:00]  <abadger1999> spot: They're two different interfaces ... We let python-psycopg and python-psycopg2 in... Or openssl and compat-openssl...
[13:00]  <scop> lutter, sure
[13:00]  <thimm> spot: e.g. perhaps there is never foo in non-gem anf gem form?
[13:00]  <spot> abadger1999: but they're not different versions. they're the same version.
[13:01]  <spot> same sets of files.
[13:01]  <thimm> example?
[13:01]  <spot> just in different locations on the filesystem
[13:01]  <abadger1999> spot: True on one level.
[13:01]  <lutter> scop: so the easy way to do gem -> non-gem would be to stick a file with "require 'rubygems'; require 'foo'" in the right place, but you are playing dirty tricks with hte lib search path if that works at all
[13:01]  <spot> the rubygem package would have files in: /usr/lib/ruby/gems/1.8/gems/rmail-0.17
[13:02]  <spot> the nongem would have the same files in /usr/lib/ruby/1.8/rmail
[13:02]  <abadger1999> spot: The user of the application is only going to care whether the application packager added the correct Requires: tag, though.
[13:02]  <spot> eh, ok. i'll go with "must not conflict with each other"
[13:03]  <scop> lutter, but I mentioned "require_gem", not "require" for the proposed wrapper, wouldn't that work?
[13:03]  <scop> s/for/in/
[13:03]  <lutter> scop: hehe .. would at least be worth a try
[13:03]  <abadger1999> I gotta jet.  lutter, the only things I saw last night were 1) the doc files aren't tagged %doc.  This can be fixed in your proposal pretty easily, though.
[13:03]  <tibbs> Would a symlink between those directories not work well enough?
[13:04]  <abadger1999> 2) I didn't delve in far enough to understand why the cahce/*.gem file is created.
[13:04]  <spot> tibbs: yes, it should, but its extra packager work
[13:04]  <tibbs> Everything is extra packager work, though.
[13:04]  <abadger1999> I'll catch up on whatever you guys discuss later :-)
[13:04]  <tibbs> Certainly less work than maintaining a second non-gem package, assuming it works.
[13:05]  <spot> i'd certainly be a lot happier with that.
[13:05]  <spot> but the problem is the reverse
[13:05]  <spot> taking a non-gem package, can't easily gem it
[13:06]  <spot> of course, i suppose if a gem version came up, you could rework the non-gem package
[13:06]  <tibbs> But then no code will ever want to call it as a gem.
[13:06]  <spot> lutter: willing to do some testing to see how painful it would be to make a "merged" package that has the gem and symlinks?
[13:07]  <lutter> spot: sure, I think that would work fairly easily
[13:07]  <spot> i think thats ideal.
[13:07]  <lutter> spot: what do we do in that case though if a non-gem pacakge already exists ?
[13:07]  <scop> Obsoletes/Provides
[13:07]  <spot> lutter: rework it to use the gem
[13:07]  <lutter> spot: should the gem package obsolete it ?
[13:07]  <thimm> require_gem seems to have been obsoleted
[13:07]  <spot> i'd argue we dont need rubygem-*
[13:07]  <spot> we can just use ruby-*
[13:07]  <lutter> thimm: you can use just 'gem'
[13:08]  <spot> it either provides both gem and nongem, or just nongem
[13:08]  <spot> thus, ruby-* is always right
[13:08]  <lutter> spot: the reason I went with the rubygem prefix is to make it easy to tell which packages provide the gem, also
[13:08]  <thimm> Seems like modern rubygems have a "require-hack"
[13:08]  <tibbs> Makes sense to me if it's possible.
[13:09]  <thimm> require 'rubygems'
[13:09]  <thimm> require 'foolib'
[13:09]  <lutter> spot: so that people that have a gem that's not apckaged as an rpm (think inhouse app) have an easy way t otell which gem deps they can satisfy with rpm's
[13:09]  <thimm> So it's rather source compatible
[13:09]  <thimm> If both packages are available which one would be preferred?
[13:09]  <spot> lutter: maybe subpackage it?
[13:09]  <lutter> thimm: except you need the 'require "rubuygems"' first
[13:09]  <thimm> See above
[13:10]  <spot> ruby-foo with a Required subpackage of rubygem-foo
[13:10]  <lutter> spot: I don't understand
[13:10]  <spot> (gem case)
[13:10]  <spot> ruby-foo
[13:10]  <spot> (non-gem case)
[13:10]  <spot> merged SRPM, but it makes two RPMS
[13:11]  <spot> if your app only needs the gem, rubygem-foo
[13:11]  <thimm> Scenario:
[13:11]  <thimm> I have foo requireing bar (gems) and baz (no gems):
[13:11]  <thimm> require 'rubygems'
[13:11]  <thimm> require 'bar'
[13:11]  <thimm> require 'baz'
[13:11]  <thimm> Suddenly bar and baz get a gem/non-gem buddy, what happens?
[13:11]  <spot> if your app uses the non-gem, you get both
[13:11]  <spot> (since the non-gem package is just symlinks)
[13:12]  <spot> lutter: you with me? :)
[13:12]  <scop> sorry folks, my time's up for tonight, see ya later
[13:12]  <lutter> spot: sorta, though I still don't see what the extra subpackage buys us; we already have provides of 'ruby(foo)' for normal ruby packages
[13:13]  <spot> lutter: ok.
[13:13]  <spot> i've got an app, called NonGemApp
[13:13]  <thimm> I need to run as well, see ya!
[13:13]  <lutter> and should add 'rubygem(foo)' for the gems if people really need to express a differnece there in the requirements
[13:13]  <spot> It uses the NonGem packaged lib
[13:13]  <spot> i've got another app called GemApp
[13:13]  <spot> It uses the Gem packaged lib
[13:14]  <spot> I want the lib to be in one SRPM
[13:14]  <spot> not two
[13:14]  <spot> so, the SRPM makes two packages
[13:14]  <spot> ruby-lib and rubygem-lib
[13:14]  <spot> rubygem-lib has the actual bits
[13:14]  <spot> ruby-lib is just symlinks and directories
[13:14]  <spot> (ruby-lib requires rubygem-lib)
[13:15]  <lutter> only the symlinks for the actual code ?
[13:15]  <spot> yes.
[13:15]  <f13> that seems pretty sane to me
[13:15]  <f13> much like some of the -devel stuff is just symlinks
[13:15]  <lutter> why not stick that all into one rpm ?
[13:15]  <f13> tightens security up a bit.
[13:15]  <spot> lutter: because of naming.
[13:16]  <spot> ruby-lib means (files not in gem packaging)
[13:16]  <spot> because it is possible to have a library that is entirely non-gem
[13:16]  <lutter> spot: but you still pull in rubygesm and rubygem-foo when you install ruby-foo
[13:16]  <f13> lutter: we probably can't exect every ruby package to generate gem links do we?
[13:16]  <spot> in the non-gem case, you just make ruby-lib
[13:16]  <lutter> we're just giving the impression it's non-gem, when in reality it is
[13:16]  <spot> which has actual bits
[13:17]  <lutter> f13: the discussion is about going the other way: have gem, make it look like non-gem
[13:17]  <spot> if i install ruby-lib, i don't get gem bits
[13:17]  <spot> if i install rubygem-lib, i get gem bits
[13:17]  <lutter> spot: with your proposal, you do
[13:17]  <spot> now, you might also get gem bits with ruby-lib
[13:17]  <lutter> spot: ruby-lib has to depend on rubygem-lib, which ahs to depend on rubygems
[13:17]  <spot> but you always get the non-gem layout
[13:17]  <f13> lutter: lets clarify something.  Every single ruby package in Fedora will have a gem?
[13:18]  <lutter> f13: no, not necessarily
[13:18]  <spot> lutter: yes.
[13:18]  <f13> lutter: then we have to have the name spacing
[13:18]  <spot> ruby-lib (unless its a non-gem source) deps on rubygem-lib, which deps on rubygems
[13:18]  <f13> lutter: or else you would R something expecting gem layout and not have it there.
[13:18]  <spot> there are two cases that need to be handled
[13:18]  <spot> gem sources and non-gem sources
[13:18]  <spot> if gem source is available, use it, make ruby-lib just symlinks
[13:19]  <-- mdomsch has left this server (Remote closed the connection).
[13:19]  <spot> if non-gem source is only option, no rubygem-lib, ruby-lib has bits
[13:19]  <lutter> spot: f13: what problem are we trying to solve here ? I am mightlily confused
[13:19]  <lutter> spot: I am with you this far
[13:19]  <spot> lutter: ok.
[13:19]  <spot> now, in order to do that with ONE SRPM for both rubygem-lib and ruby-lib
[13:19]  <lutter> spot: ok .. but you want ot make the ruby-foo package mandatory for all rubygem-foo pacakges ? I would leave that optional
[13:20]  <spot> lutter: no, i dont think it needs to be optional
[13:20]  <spot> err... i dont think it needs to be mandatory. :)
[13:20]  <spot> BUT
[13:20]  <lutter> spot: if you want ruby-foo and there is a rubygem-foo it has to be done with symlinks ?
[13:20]  <spot> exactly
[13:20]  <spot> and as a subpackage
[13:20]  <spot> not two SRPMS
[13:20]  <lutter> phew .. ok .. I agree with that
[13:21]  <lutter> ok
[13:21]  <spot> if a gem is available, you need to use it.
[13:21]  <spot> (to make the package_
[13:22]  <spot> because it is easier to use the gem to make both packages
[13:22]  <tibbs> That makes good sense.
[13:22]  <lutter> spot: other queastion: if gem A requires gem B, we'll have rubygem-A R rubygem-B; does that need to be written out for ruby-A and ruby-B, since it's implied from the rubygem- level ?
[13:22]  <tibbs> The only question is whether it's actually possible to do that for all packages in reality.
[13:23]  <spot> lutter: nope.
[13:23]  <lutter> tibbs: yeah, I'll do a little bit of experimenting
[13:23]  <spot> only time you'd need ruby-A R ruby-B is if either of them was made from non-gem source
[13:23]  <lutter> spot: ok .. then I can probably extend gem2spec to generate the ruby-foo subpackages, too
[13:24]  <spot> lutter: should be able to, yes.
[13:25]  <spot> lutter: ok, test it, we'll look at the rewrite next week
[13:25]  <lutter> spot: will do
[13:25]  <spot> ok, we're overtime, thanks all
[13:25]  <tibbs> I'll write it up.
[13:29]  * spot updates GuidelinesTodo
[13:29]  * spot updates DraftsTodo