Packaging:Minutes20070320

From FedoraProject

Revision as of 03:20, 21 December 2008 by Wikibot (Talk | contribs)
(diff) ← Older revision | Current revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Contents

Fedora Packaging Committee Meeting of {2007.03.20}

Present

The entire committee was present:

Writeups

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

Votes

The following proposals were considered:

Other Discussions

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


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
Retrieved from "https://fedoraproject.org/wiki/Packaging:Minutes20070320"