17:19:36 <abadger1999> #startmeeting fpc
17:19:36 <zodbot> Meeting started Wed Mar 28 17:19:36 2012 UTC.  The chair is abadger1999. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:19:36 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:19:46 <abadger1999> #topic Roll Call
17:19:47 * geppetto is here
17:19:51 <abadger1999> Who's here?
17:19:54 * mmorsi is
17:19:59 * bkabrda is
17:20:22 <geppetto> rdieter: ping
17:20:24 <geppetto> racor: ping
17:20:26 <abadger1999> rdieter, racor, spot, SmootherFrOgZ: ping fpc meeting
17:20:35 <rdieter> hola
17:20:49 <abadger1999> #chair geppetto rdieter tibbs|h
17:20:49 <zodbot> Current chairs: abadger1999 geppetto rdieter tibbs|h
17:21:08 <abadger1999> With tibbs|h we have four
17:21:17 * SmootherFrOgZ is here
17:21:22 <abadger1999> five
17:21:28 <geppetto> ok, got there :)
17:21:33 <abadger1999> #chair SmootherFrOgZ
17:21:33 <zodbot> Current chairs: SmootherFrOgZ abadger1999 geppetto rdieter tibbs|h
17:22:20 <abadger1999> Since we have members of the ruby SIG here do we want to start with that or should we get some less contentious items out of hte way first ;-)
17:22:36 <geppetto> Nah, we said we'd start with it
17:22:52 <bkabrda> thanks guys :)
17:23:10 <abadger1999> #topic Ruby Guidelines -- https://fedorahosted.org/fpc/ticket/134
17:23:15 <racor> abadger1999: /me is here for the next 5 mins (17:00 UTC during DST doesn't work for me)
17:23:25 <geppetto> From what I've seen we are just voting on your proposal from last week anyway … and it didn't seem that contentious anymore, right?
17:23:28 <abadger1999> https://fedoraproject.org/wiki/User:Toshio/RubyPackagingDraft
17:24:00 <bkabrda> geppetto: there is this thing with Provides for rubygems... as I mention in my last comment in the ticket
17:24:16 <tibbs|h> So the REQUIRE_PATHS thing ends up being manual?
17:24:49 <abadger1999> tibbs|h: yeah
17:25:03 <geppetto> bkabrda: Did you, or someone else, reply with abadger1999 three points of why it doesn't matter?
17:25:19 <tibbs|h> abadger1999: Is that something that's required regardless of whether we decide to do the split %prep/%build/%install thing?
17:25:30 <abadger1999> tibbs|h: Correct
17:25:58 <bkabrda> geppetto: I'm not sure what you mean
17:26:00 <mmorsi> tibbs|h: abadger1999 i think bkabrda is refering to the rubygem packages being required to provider ruby(modulename)
17:26:17 <bkabrda> mmorsi: yeah
17:26:19 <tibbs|h> abadger1999: Good to know.  Thanks.
17:26:38 <geppetto> mmorsi: Right … but as abadger1999 said, that doesn't really matter because it's an rpm thing and not a ruby thing.
17:27:04 * geppetto tries to find the message to the list.
17:27:06 <mmorsi> tibbs|h: abadger1999 basically if rubygem-foo having to provider ruby(foo)  leads to conflict for other packages which provide ruby(foo)
17:27:20 <bkabrda> geppetto: it is a ruby thing. if you have ruby-foo and rubygem-foo, which are different libraries and both will provide ruby(foo), then you have a problem
17:27:47 <mmorsi> ruby has a few postgres driver implementations
17:27:50 <abadger1999> mmorsi: That seems to already be the case
17:27:55 <mmorsi> a few rubygems based, a few not
17:28:03 <abadger1999> require 'foo';
17:28:13 <mmorsi> so if all provide ruby(pg) there are going to be unecessary conflicts
17:28:24 <abadger1999> will have to choose whether to import the rubygem version or the non-gem version based on the ruby path.
17:28:31 <tibbs|h> You are using a different definition of "conflict" than I'm used to.
17:28:36 <geppetto> bkabrda: The message posted on: Fri, 2 Mar 2012 08:29:08 -0800 (03/02/2012 11:29:08 AM)
17:28:41 <bkabrda> abadger1999: but when you Require: ruby(foo) in the specfile, how can you be sure what it will draw in?
17:29:27 <racor> I've got to quit. Please consider to change the meeting time to 16:00UTC or earlier
17:29:45 <geppetto> mmorsi: Provides don't conflict, it just means that if someone does "yum install ruby(blah)" … yum will have to decide between multiple providers.
17:29:47 <bkabrda> abadger1999: and if the ruby developer has both ruby-foo and rubygem-foo installed, it's his problem to manage that
17:30:17 <bkabrda> geppetto: yes, but the provided functionalities/APIs differ
17:30:40 <abadger1999> bkabrda: You can't know that it's going to draw in regardless.  It's a virtual provide which could be satisfied by several packages -- if you want a specific package... stick to package deps
17:31:16 <mmorsi> yes again seems to be the case which it might make sense to require the package dependencies to be a bit more explicit
17:31:19 <geppetto> bkabrda: Kind of, again … in abadger1999's cases #1 and #3, but in case #2 everything is "correct" but it still doesn't work == it's not useful.
17:32:00 <geppetto> mmorsi: bkabrda: Do either of you have an example where ruby(foo) and rubygem(foo) helps anything?
17:32:28 <bkabrda> ruby-postgres, rubygem-postgres (ok, this one is not in Fedora yet).
17:32:53 <abadger1999> racor: Thanks -- We'll likely post to the mailing list with the request to schedule earlier.
17:33:18 <bkabrda> they have different APIs, but if both will provide ruby(postgres), then you have a problem when requiring ruby(postgres) in specfile
17:33:45 <mmorsi> hrm well it seems that adding the ruby(foo) to the rubygem packages would be the route involving more work, so why wouldn't we just go w/ the simpler / more explicit route
17:34:04 <geppetto> By different APIs do you really mean different APIs, or just the difference in that one is a gem and one isn't (so one doesn't work with --disable-gems)?
17:34:23 <bkabrda> I mean really different APIs, as in different functionality
17:34:49 <geppetto> Then they really shouldn't be different just in ruby(foo) vs. rubygem(foo) … but ruby(foo) and ruby(bar), IMNSHO.
17:35:03 <rdieter> geppetto: +1
17:35:18 <bkabrda> geppetto: how so? will you convince upstream to rename?
17:35:21 <abadger1999> Package A Requires: ruby(postgres)  Package B Requires: rubygem(postgres).  I install both Package A and Package B on the system.  They drag in both ruby-postgres and rubygem-postgres.  One of Package A or Package B is broken.
17:35:24 <tibbs|h> geppetto: What happens if a package has multiple requires, one of which is provided by, say, three packages and the other is provided by exactly one of those packages?
17:35:47 <tibbs|h> Sorry, that's a question about what yum would do in that situation.
17:35:51 <geppetto> tibbs|h: Depends … yum will sometimes install 2 things
17:36:08 <tibbs|h> Ugh, OK.
17:36:11 <geppetto> tibbs|h: Ofc. that might get fixed at some point.
17:36:20 <bkabrda> geppetto: as mmorsi said, why not to go the more obvious way?
17:36:32 <tibbs|h> I was hoping it would notice that the specific dependency would satisfy the non-specific one.
17:36:40 <abadger1999> So why are we doing virtual provides anyway?
17:36:51 <geppetto> tibbs|h: There are ways to get yum to deal with the more specific one first … and then it'll just work.
17:37:00 <bkabrda> abadger1999: because we can have two different gems that have the same functionality
17:37:26 <geppetto> bkabrda: So now we have two packages providing rubygem(foo) ?
17:37:40 <bkabrda> geppetto: yes
17:37:49 <abadger1999> bkabrda: could you give me an example?
17:37:58 * abadger1999 would like to look at the spec files for these
17:38:05 <geppetto> And arbitrarily splitting provides on ruby(foo) vs. rubygem(foo) helps this how?
17:38:09 <bkabrda> abadger1999: it is only a concept, AFAIK there none so far
17:38:34 <mmorsi> hrm this splitting is not arbitrary
17:38:51 <geppetto> mmorsi: It certainly looks that way from here.
17:38:54 <abadger1999> bkabrda: Then I say, this is a theoretical problem that affects *all* languages equally.
17:38:55 <mmorsi> ruby(foo) indicates rubygems is not needed employed where rubygem(foo) indicates others
17:38:58 <mmorsi> otherwise
17:39:11 <geppetto> mmorsi: But that's not true, in abadger1999's case #2
17:39:27 <abadger1999> Upstreams know that they're asking for hurt when they do it... and we cross that bridge individually whenever we encounter it in other languages.
17:39:50 <mmorsi> case #2?
17:39:56 <abadger1999> Well.. I guess upstreams don't know that they're asking for hurt... But we're always available to tell them ;-)
17:40:49 <geppetto> mmorsi: http://lists.fedoraproject.org/pipermail/packaging/2012-March/008224.html
17:41:22 <geppetto> Bah … actually case #1
17:41:52 <geppetto> foo => requires ruby(blah) … blah => rubygem(xyz) … here foo fails with --disable-gems.
17:42:22 <mmorsi> if you --disable-gems how can you expect something to work that depends on gems?
17:42:28 <bkabrda> geppetto: yes, but that is a problem of the upstream and the way they tell you to run their application
17:42:34 <geppetto> So just requiring ruby(blah) does not guarantee that you don't need rubygems() to be working … hence is is pointless splitting of the namespace.
17:43:07 <mmorsi> all the more case to have something that requires rubygems explicity require rubygem(pkg)
17:43:18 <mmorsi> in case #1
17:43:38 <mmorsi> why is latte only packaged as a gem when it needs to be used in a non-gem environment?
17:43:47 <mmorsi> or alternatively
17:43:58 <mmorsi> why is mocha not packages by a gem if it has a gem dependency?
17:44:29 <mmorsi> http://rubygems.org/gems/mocha
17:44:37 <geppetto> mmorsi: If you can guarantee one of those two assertions, then I'm happy to leave the split.
17:44:41 <bkabrda> I guess we are trying to say that this won't happen in ruby world
17:45:02 <geppetto> But from what I could see, that's not guaranteed atm. … each package is free to be a gem or not whenever it wants.
17:45:17 <bkabrda> geppetto: I can't guarantee that, but I don't know any ruby developer who would do such a thing
17:45:29 <mmorsi> well
17:45:37 <mmorsi> right now if its shipped via rubygems
17:45:44 <geppetto> bkabrda: So we have these things called policies that make assertions about things :)
17:45:51 <mmorsi> and we package it, we package it as rubygem-foo
17:46:12 <mmorsi> if its not shipped via rubygems its packaged as ruby-foo
17:46:29 <geppetto> bkabrda: So basically … if you want to calter the policy to explicitly state that nothing providing a ruby(foo) will ever requiring a rubygem(bar) … then leaving the split in seems ok
17:46:41 <mmorsi> no
17:47:00 <mmorsi> i think the ideal solution is that if there is a rubygem dependency in your dep chain you can't use --disable-gems
17:47:10 <mmorsi> else if you do how do expect things to work?
17:47:23 <geppetto> And that works just fine, with or without the ruby/rubygem namespace split.
17:47:34 <abadger1999> mmorsi: My point exactly.... and that's something that occurs on the end user's system.. not in packaging.
17:47:38 <mmorsi> no because else how will the rubygem dependency be represented
17:48:13 <geppetto> mmorsi: Again, what we are saying is that, if you want to "represent" the rubygem dependency you need to do so in a way that is not going to break.
17:48:27 <abadger1999> which means, that for packaging... the split doesn't do any good.
17:48:36 <bkabrda> geppetto: yes, exactly. that is it should provide rubygem(foo)
17:48:58 <geppetto> bkabrda: And that no ruby package can depend on any rubygems.
17:49:07 <bkabrda> geppetto: why?
17:49:26 <geppetto> Because doing so doesn't work.
17:49:36 <bkabrda> geppetto: you can have ruby packages that will and ruby packages that won;t
17:49:57 <bkabrda> geppetto: how does it not work?
17:50:14 <geppetto> At which point the gems split is meaningless … you can't have it both ways.
17:50:50 <bkabrda> geppetto: I really fail to see your point at this
17:50:50 <geppetto> bkabrda: PkgA requires ruby(foo) but still breaks when --disable-gems.
17:51:05 <bkabrda> geppetto: and where is the problem?
17:51:40 <bkabrda> geppetto: it is the duty of the upstream to say that you can/can't run it with --disable-gems
17:51:42 <geppetto> bkabrda: If there is no problem there then rubygem(foo) == ruby(foo) … so we don't need the split namespace.
17:52:32 <bkabrda> geppetto: but then again, you have 2 packages ruby-foo and rubygem-foo with different functionality. both provide ruby(foo), which you require in a specfile. what happens then?
17:52:55 <geppetto> It's very simple … either: 1) rubygem() means something, so we add effort to provide that meaning. 2) ruby(foo) doesn't guarantee anything that rubygem(foo) doesn't, so just merge the namespace.
17:53:18 <geppetto> bkabrda: Again, no. If they have different functionality they shouldn't split just based on ruby/rubygem.
17:53:39 <geppetto> That is complete insanity.
17:53:48 <bkabrda> geppetto: but it works that way in Ruby world
17:54:04 <tibbs|h> But this isn't about the ruby world; this is about Fedora package dependencies.
17:54:05 <mmorsi> well we need rubygem() incase a dependency has an explicit 'gem foo' requirement
17:54:39 <abadger1999> mmorsi: +1
17:54:46 <bkabrda> tibbs|h: that's precisely what I'm saying. what does require ruby(foo) tell you then?
17:54:52 <abadger1999> it's the other way that we're not so sure is interesting.
17:54:54 <mmorsi> so there needs to be a ruby() / rubygem() distinction anyways the only question is if packages that provide rubygem(foo) als0o need to proviide ruby(foo)
17:55:06 <abadger1999> Proposal -- get rid of the virtual Provides.  They are covering a corner case that we are not running into in practice and is worked around on a package-by-package basis in other languages.
17:55:41 <tibbs|h> I don't have a particular problem with that, but the whole thing is there to basically cover the possibility of RPM auto-discovering this stuff.
17:55:49 <geppetto> Yeh, that works too, the only reason we have perl(foo) is because it's done automatically by rpmbuild.
17:55:49 <abadger1999> Without virtual provides, this conflict becomes moot -- packagers wil Require: the exact packagename -- which will contain ruby-  or rubygem- depending on how they are packaged.
17:55:57 <tibbs|h> Not that I think that it has any chance of getting these bizarre subtleties right.
17:56:01 <bkabrda> abadger1999: hmm, that might actually do it
17:56:09 <mmorsi> a rubygem providing ruby(foo) involves more work, and doesn't indicate that a package requires rubygems to work
17:56:39 <mmorsi> and the review guidlines state "the review should test the package functions as described"
17:56:45 <mmorsi> granted thats a should
17:57:22 <geppetto> Ok … so voting on https://fedoraproject.org/wiki/User:Toshio/RubyPackagingDraft … with the section on "Provides" removed?
17:57:57 <mmorsi> not the entire section just the bit about 'rubygems' requiring to provide ruby()
17:58:14 <geppetto> No … the entire section.
17:58:44 <geppetto> abadger1999: Right?
17:58:47 <tibbs|h> Indeed; I see nothing in that section that should stay if we jettison the virtual provides stuff.
17:58:49 <abadger1999> The whole Dependencies section should o I think.
17:58:57 <abadger1999> *should go
17:59:10 <geppetto> Oh, yeh … the requires are just about using the provides … so, yeh.
17:59:20 <rdieter> right
17:59:52 <tibbs|h> Oh, the ruby(abi) thing isn't in the Dependencies section at all.  Odd, but sure, dump the whole thing.
18:00:05 <geppetto> Yeh
18:00:10 <geppetto> So, I'm +1.
18:00:26 <abadger1999> mmorsi: Did that make sense -- by geting rid of virtual provides (and requires of those) packagers will just use package names which already contain ruby- or rubygem- in the name.
18:01:06 <mmorsi> ya it makes sense, essentially amounts to what we have now, just no syntax w/ the ()
18:01:25 <bkabrda> abadger1999: mmorsi: agreed
18:01:31 * mmorsi personally likes the virtual provides but suppose thats a matter of personal preference
18:01:35 * abadger1999 strikes that
18:01:44 <abadger1999> Page updated: https://fedoraproject.org/wiki/User:Toshio/RubyPackagingDraft
18:02:01 <bkabrda> abadger1999: two more small things if I may
18:02:03 <mmorsi> it will be a bit of work updating all the packages but again not a blocker there
18:02:09 <mmorsi> and it does simplify things in the long run
18:02:21 <bkabrda> abadger1999: Ad https://fedoraproject.org/wiki/User:Toshio/RubyPackagingDraft#RSpec - we have fixed some dependencies here according to the upstream, so packagers should have BuildRequires: rubygem(rspec) from F17 on.
18:02:51 <bkabrda> abadger1999: not rubygem(rspec-core)
18:03:03 <bkabrda> abadger1999: and without the virtual provides of course
18:03:11 <geppetto> bkabrda: Which will now be rubygem-rspec … right?
18:03:12 <mmorsi> ah ya good catch
18:03:13 * geppetto nods
18:03:17 <bkabrda> geppetto: right
18:03:30 <geppetto> Ok, seems fine.
18:03:32 <geppetto> What's the other thing?
18:03:48 <bkabrda> Ad https://fedoraproject.org/wiki/User:Toshio/RubyPackagingDraft#Patching_required_gem_versions - there should be an explicit 'must', that would require the packager to test if the package actually works with the different version of other gems.
18:04:07 <abadger1999> Updated: "To run tests using RSpec >= 2 you must BuildRequires: rubygem-rspec and use something like: "
18:04:36 <bkabrda> because sometimes the developers really put the restrictions for a reason (not so often, but they do)
18:04:54 <geppetto> bkabrda: Well it already says "but we know that a different version will also work"
18:05:09 <geppetto> But if you have alternate wording, that seems fine.
18:05:16 <bkabrda> geppetto: I was just thinking more explicit would be better
18:05:22 <mmorsi> yeh tend to like leaving it as is myself
18:05:37 <mmorsi> afterall the guidelines already say a reviewer should test the package
18:05:50 <mmorsi> but nbd either way
18:06:43 <abadger1999> How's this sound: {{admon/warning|Be sure to test|Do not simply change versions without testing that the new version works.  There are times the upstream is overly strict but there are also times when the version requirement was specified because a specific bug was encountered or the API changed in a minor release.}}
18:07:01 <bkabrda> abadger1999: there is a Requires: rubygem(haml) in the https://fedoraproject.org/wiki/User:Toshio/RubyPackagingDraft#Applications, that should probably go away...
18:07:12 <bkabrda> abadger1999: yes, that's very good
18:07:17 <mmorsi> +1
18:07:46 <geppetto> abadger1999: And another rubgygem(minitest) in the MiniTest section.
18:08:04 <geppetto> And rubygem(test-unit).
18:08:16 <geppetto> That's it, AFAICS.
18:08:47 <bkabrda> yes... btw it will take us some time to migrate all the new packages to conform with the new guidelines, but I think they are pretty much compatible, so it shouldn't be a big problem
18:09:00 * geppetto nods … that's fine.
18:09:06 <bkabrda> *new packages => packages
18:09:06 * limburgher is back
18:09:41 <geppetto> Ok, with those changes … I'm +1 again.
18:10:27 <abadger1999> Okay, those changes all made
18:10:53 <abadger1999> <nod> I'm fine with a transition.
18:11:20 <bkabrda> no problems on my side
18:11:27 <tibbs|h> FPC doesn't generally mandate any retroactive changes anyway.
18:11:42 <abadger1999> mmorsi, bkabrda: Did the things that need to be changedin https://fedoraproject.org/wiki/User:Toshio/RubyPackagingDraft#Some_notes
18:11:47 <abadger1999> seem complete and okay?
18:12:11 <mmorsi> tibbs|h: now u tell us :-p
18:12:45 <mmorsi> yeh the alternative interpreters situation needs to be figured out
18:13:01 <mmorsi> until then we can just go w/ the current draft, dropping those notes
18:13:16 <bkabrda> abadger1999: " Need to move the rubygems library into the per-interpreter directories as it is a non-gem library. " - we are working on getting it working with all the interpreters, so it should probably stay where it is
18:13:32 <mmorsi> as soon as we have more info regarding that, we'll get back to ya'll w/ more info
18:13:57 <abadger1999> bkabrda: well... that was part of the "vendordir-is-interpreter-independent" discussion... probably a minor branch off of it.
18:14:13 <tibbs|h> Minor question: the sections near the end, "To run tests using *".  How do I know which is required?
18:14:43 <bkabrda> tibbs|h: from Rakefile
18:14:48 <mmorsi> hrm well for rspec there will usually be a 'specs' dir
18:15:01 <mmorsi> or a 'spec' dir
18:15:08 <abadger1999> I was against specialcasin rubygems and someone, I don't remember who though, said that they'd be open to simply moving the rubygems module back into the vendordir (or back into the stdlib of each ruby interpreter)
18:15:15 <abadger1999> *specialcasing
18:15:30 <mmorsi> honestly not sure about test unit / minitest
18:15:43 <mmorsi> might just be a per-project thing
18:15:59 <mmorsi> or like bkabrda said the rakefile will be biggest indication
18:16:00 <tibbs|h> Approaching this from the standpoint of a package reviewer who may not be a ruby expert, I'm just trying to figure out how to tell if there are tests which should be run.
18:16:08 <mmorsi> understood
18:16:12 <bkabrda> abadger1999: well I don't remember that, but we are working to get rubygems working with all the interpreters... they almost work with jruby already (in my testing environment)
18:16:19 <mmorsi> ya check the rakefile, thats your best bet
18:16:28 <abadger1999> bkabrda: I'm still somewhat against special-casing.  What do we gain by specialcasing rubygems in this way?
18:16:37 <mmorsi> either 'minitest' or 'unit' or 'rspec' will be included there
18:16:53 <mmorsi> (in the vast majority cases, eg all the ones i've seen)
18:17:57 <bkabrda> abadger1999: well, there is in fact no reason not to have one system rubygems, if it is possible. for example, you will be able to use one command "gem install" and not "jgem install" for jruby rubygems
18:18:45 <mmorsi> gem expects certain things about the gems path to work too
18:19:43 <abadger1999> bkabrda: why can't we have that and  still have the rubygems module live in the vendorlibs/per-interpreter-stdlibs?
18:21:17 <abadger1999> (note rubygems packages would live in /usr/share/rubygems... just the rubygem module would be in the per-interpreter area)
18:21:26 <bkabrda> abadger1999: but which gems would then "gem" command use? and essentially, if there is a CVE for rubygems, you get to fix it once. (although jruby rubygems are not compatible with the MRI ones, they are mostly the same and security fixes would probably apply to both in the same way)
18:21:39 <bkabrda> abadger1999: yes, I understand that
18:23:16 <abadger1999> The gem command is run by a ruby interpreter?  Then it'll use the rubygem module associated with that interpreter.
18:23:34 <abadger1999> The CVE argument applies to anything in vendorlib, though.
18:23:54 <abadger1999> which we've already decided is not desirable to share between ruby interpreters.
18:23:57 <bkabrda> abadger1999: the gem command is run just like that. it has a shebang
18:24:37 <bkabrda> abadger1999: yes, the vendorlib shouldn't be shared, because it will mostly contain non-shareable libraries. but we will make rubygems shareable, it's on the way
18:26:18 <abadger1999> bkabrda: but I'm still not seeing why we should specialcase that... For instance, why should we not have an "interpreter-neutral-vendorlib" where rubygem module and other non-gem modules that are shareable live?  What is it that makes rubygem worthy of specialcasing?
18:26:33 <abadger1999> especially since it's not there yet and requires work by us to enable?
18:28:02 <bkabrda> abadger1999: well, rubygems can be shareable in future, so we should make them shareable. we are just taking it step by step
18:28:26 <abadger1999> bkabrda: okay... but there's non-gem modules that are shareable now.  So shouldn't we be prioritising those?
18:29:02 <bkabrda> abadger1999: no, because these are not so heavily used
18:30:23 * SmootherFrOgZ has to run for a few minutes.
18:30:33 <abadger1999> okay -- so the deciding factor is whether we should specialcase rubygems because they are heavily used.
18:30:35 <bkabrda> abadger1999: in fact, I think you would have a hard time trying to find non-gem libraries that work with all the interpreters. and it's the intention of their upstreams. but rubygems should be shareable
18:31:11 <bkabrda> abadger1999: mostly. yes
18:31:43 <bkabrda> but as I said, having one "gem" command is a huge advantage, for example
18:32:16 <mmorsi> arg wireless died
18:32:35 <abadger1999> bkabrda: but -- I don't see that you'd have multiple gem commands so that doesn't seem to be a reason.
18:33:05 <bkabrda> abadger1999: you have gem and jgem for instance
18:33:36 <abadger1999> (also -- you probably eventually do want multiple gem commands -- or you need a front end shell script to run the "right" gem command depending on what interpreters are present on the system)
18:33:56 <abadger1999> otherwise you have a jruby system that drags in ruby just so the gem command works.
18:34:19 <abadger1999> bkabrda: But if the backend is neutral, in packaging you simply %exclude %{_bindir}jgem
18:34:31 <bkabrda> abadger1999: that's precisely what we don't want. when we get to the state that the system gems work with jruby, we will strip their dependency on MRI ruby
18:35:37 <abadger1999> bkabrda: right -- I'm saying that the shebang doesn't work when you do that.
18:35:42 <bkabrda> abadger1999: stripping jgem will prevent users from using jrubygems - and any gems with jruby for that matter
18:36:13 <abadger1999> why?  ruby calls out to the %{_bindir} script in order to use gems?
18:37:19 <bkabrda> abadger1999: if you will have "gem" which is non-compatible with jruby for instance and will try to install some java db bindings, it will fail
18:37:37 <bkabrda> because it won't know how to compile jars
18:38:06 <abadger1999> bkabrda: okay.  So then for now you must have jgem installed.
18:38:15 <bkabrda> abadger1999: for now, yes
18:38:40 <abadger1999> which means that we should not be special casing rubygems.
18:38:49 <abadger1999> we need two separate implementations.
18:38:57 <bkabrda> what is the problem in taking this step by step?
18:39:31 <abadger1999> probably that we don't know what the steps are :-)
18:39:43 <abadger1999> I should be in another meeting now.
18:39:44 <bkabrda> 1) take rubygems out of MRI ruby
18:39:54 <mmorsi> srry if i missed anything but gem requires the directory structure to be setup the way it is
18:39:59 <bkabrda> 2) make them work with both Jruby and MRI ruby
18:40:12 <abadger1999> So we probably need to stop this meeting and continue this paricular portion of the discussion later.
18:40:22 <bkabrda> first step is done, second will be
18:40:42 <mmorsi> it does some path manipulation and what not, eg expects the specifications to be in locations relative to the gem path, etc
18:40:47 <abadger1999> Seems better to do them in the other order.
18:41:03 <bkabrda> I don't really see why
18:41:45 <abadger1999> mmorsi, bkabrda: Could you write up the constraints that you see and send to the packaging list?  I don't have a concrete understanding of what you're saying are constraints
18:41:55 <abadger1999> so I can't evaluate.
18:42:03 <bkabrda> we thought we would make that into F17, we didn't.
18:42:18 <bkabrda> but why would we revert half of the work?
18:42:40 <bkabrda> it will get there, it just needs a bit more time
18:42:59 <abadger1999> why would you start work by making the "finalize this" type of change?
18:43:07 <abadger1999> anyway...
18:43:18 <abadger1999> We're well over time
18:43:37 <bkabrda> ok, so I guess we'll discuss this on the list
18:43:42 <abadger1999> Thanks
18:43:44 <abadger1999> #endmeeting