17:19:36 #startmeeting fpc 17:19:36 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 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:19:46 #topic Roll Call 17:19:47 * geppetto is here 17:19:51 Who's here? 17:19:54 * mmorsi is 17:19:59 * bkabrda is 17:20:22 rdieter: ping 17:20:24 racor: ping 17:20:26 rdieter, racor, spot, SmootherFrOgZ: ping fpc meeting 17:20:35 hola 17:20:49 #chair geppetto rdieter tibbs|h 17:20:49 Current chairs: abadger1999 geppetto rdieter tibbs|h 17:21:08 With tibbs|h we have four 17:21:17 * SmootherFrOgZ is here 17:21:22 five 17:21:28 ok, got there :) 17:21:33 #chair SmootherFrOgZ 17:21:33 Current chairs: SmootherFrOgZ abadger1999 geppetto rdieter tibbs|h 17:22:20 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 Nah, we said we'd start with it 17:22:52 thanks guys :) 17:23:10 #topic Ruby Guidelines -- https://fedorahosted.org/fpc/ticket/134 17:23:15 abadger1999: /me is here for the next 5 mins (17:00 UTC during DST doesn't work for me) 17:23:25 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 https://fedoraproject.org/wiki/User:Toshio/RubyPackagingDraft 17:24:00 geppetto: there is this thing with Provides for rubygems... as I mention in my last comment in the ticket 17:24:16 So the REQUIRE_PATHS thing ends up being manual? 17:24:49 tibbs|h: yeah 17:25:03 bkabrda: Did you, or someone else, reply with abadger1999 three points of why it doesn't matter? 17:25:19 abadger1999: Is that something that's required regardless of whether we decide to do the split %prep/%build/%install thing? 17:25:30 tibbs|h: Correct 17:25:58 geppetto: I'm not sure what you mean 17:26:00 tibbs|h: abadger1999 i think bkabrda is refering to the rubygem packages being required to provider ruby(modulename) 17:26:17 mmorsi: yeah 17:26:19 abadger1999: Good to know. Thanks. 17:26:38 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 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 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 ruby has a few postgres driver implementations 17:27:50 mmorsi: That seems to already be the case 17:27:55 a few rubygems based, a few not 17:28:03 require 'foo'; 17:28:13 so if all provide ruby(pg) there are going to be unecessary conflicts 17:28:24 will have to choose whether to import the rubygem version or the non-gem version based on the ruby path. 17:28:31 You are using a different definition of "conflict" than I'm used to. 17:28:36 bkabrda: The message posted on: Fri, 2 Mar 2012 08:29:08 -0800 (03/02/2012 11:29:08 AM) 17:28:41 abadger1999: but when you Require: ruby(foo) in the specfile, how can you be sure what it will draw in? 17:29:27 I've got to quit. Please consider to change the meeting time to 16:00UTC or earlier 17:29:45 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 abadger1999: and if the ruby developer has both ruby-foo and rubygem-foo installed, it's his problem to manage that 17:30:17 geppetto: yes, but the provided functionalities/APIs differ 17:30:40 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 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 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 mmorsi: bkabrda: Do either of you have an example where ruby(foo) and rubygem(foo) helps anything? 17:32:28 ruby-postgres, rubygem-postgres (ok, this one is not in Fedora yet). 17:32:53 racor: Thanks -- We'll likely post to the mailing list with the request to schedule earlier. 17:33:18 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 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 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 I mean really different APIs, as in different functionality 17:34:49 Then they really shouldn't be different just in ruby(foo) vs. rubygem(foo) … but ruby(foo) and ruby(bar), IMNSHO. 17:35:03 geppetto: +1 17:35:18 geppetto: how so? will you convince upstream to rename? 17:35:21 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 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 Sorry, that's a question about what yum would do in that situation. 17:35:51 tibbs|h: Depends … yum will sometimes install 2 things 17:36:08 Ugh, OK. 17:36:11 tibbs|h: Ofc. that might get fixed at some point. 17:36:20 geppetto: as mmorsi said, why not to go the more obvious way? 17:36:32 I was hoping it would notice that the specific dependency would satisfy the non-specific one. 17:36:40 So why are we doing virtual provides anyway? 17:36:51 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 abadger1999: because we can have two different gems that have the same functionality 17:37:26 bkabrda: So now we have two packages providing rubygem(foo) ? 17:37:40 geppetto: yes 17:37:49 bkabrda: could you give me an example? 17:37:58 * abadger1999 would like to look at the spec files for these 17:38:05 And arbitrarily splitting provides on ruby(foo) vs. rubygem(foo) helps this how? 17:38:09 abadger1999: it is only a concept, AFAIK there none so far 17:38:34 hrm this splitting is not arbitrary 17:38:51 mmorsi: It certainly looks that way from here. 17:38:54 bkabrda: Then I say, this is a theoretical problem that affects *all* languages equally. 17:38:55 ruby(foo) indicates rubygems is not needed employed where rubygem(foo) indicates others 17:38:58 otherwise 17:39:11 mmorsi: But that's not true, in abadger1999's case #2 17:39:27 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 case #2? 17:39:56 Well.. I guess upstreams don't know that they're asking for hurt... But we're always available to tell them ;-) 17:40:49 mmorsi: http://lists.fedoraproject.org/pipermail/packaging/2012-March/008224.html 17:41:22 Bah … actually case #1 17:41:52 foo => requires ruby(blah) … blah => rubygem(xyz) … here foo fails with --disable-gems. 17:42:22 if you --disable-gems how can you expect something to work that depends on gems? 17:42:28 geppetto: yes, but that is a problem of the upstream and the way they tell you to run their application 17:42:34 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 all the more case to have something that requires rubygems explicity require rubygem(pkg) 17:43:18 in case #1 17:43:38 why is latte only packaged as a gem when it needs to be used in a non-gem environment? 17:43:47 or alternatively 17:43:58 why is mocha not packages by a gem if it has a gem dependency? 17:44:29 http://rubygems.org/gems/mocha 17:44:37 mmorsi: If you can guarantee one of those two assertions, then I'm happy to leave the split. 17:44:41 I guess we are trying to say that this won't happen in ruby world 17:45:02 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 geppetto: I can't guarantee that, but I don't know any ruby developer who would do such a thing 17:45:29 well 17:45:37 right now if its shipped via rubygems 17:45:44 bkabrda: So we have these things called policies that make assertions about things :) 17:45:51 and we package it, we package it as rubygem-foo 17:46:12 if its not shipped via rubygems its packaged as ruby-foo 17:46:29 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 no 17:47:00 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 else if you do how do expect things to work? 17:47:23 And that works just fine, with or without the ruby/rubygem namespace split. 17:47:34 mmorsi: My point exactly.... and that's something that occurs on the end user's system.. not in packaging. 17:47:38 no because else how will the rubygem dependency be represented 17:48:13 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 which means, that for packaging... the split doesn't do any good. 17:48:36 geppetto: yes, exactly. that is it should provide rubygem(foo) 17:48:58 bkabrda: And that no ruby package can depend on any rubygems. 17:49:07 geppetto: why? 17:49:26 Because doing so doesn't work. 17:49:36 geppetto: you can have ruby packages that will and ruby packages that won;t 17:49:57 geppetto: how does it not work? 17:50:14 At which point the gems split is meaningless … you can't have it both ways. 17:50:50 geppetto: I really fail to see your point at this 17:50:50 bkabrda: PkgA requires ruby(foo) but still breaks when --disable-gems. 17:51:05 geppetto: and where is the problem? 17:51:40 geppetto: it is the duty of the upstream to say that you can/can't run it with --disable-gems 17:51:42 bkabrda: If there is no problem there then rubygem(foo) == ruby(foo) … so we don't need the split namespace. 17:52:32 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 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 bkabrda: Again, no. If they have different functionality they shouldn't split just based on ruby/rubygem. 17:53:39 That is complete insanity. 17:53:48 geppetto: but it works that way in Ruby world 17:54:04 But this isn't about the ruby world; this is about Fedora package dependencies. 17:54:05 well we need rubygem() incase a dependency has an explicit 'gem foo' requirement 17:54:39 mmorsi: +1 17:54:46 tibbs|h: that's precisely what I'm saying. what does require ruby(foo) tell you then? 17:54:52 it's the other way that we're not so sure is interesting. 17:54:54 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 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 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 Yeh, that works too, the only reason we have perl(foo) is because it's done automatically by rpmbuild. 17:55:49 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 Not that I think that it has any chance of getting these bizarre subtleties right. 17:56:01 abadger1999: hmm, that might actually do it 17:56:09 a rubygem providing ruby(foo) involves more work, and doesn't indicate that a package requires rubygems to work 17:56:39 and the review guidlines state "the review should test the package functions as described" 17:56:45 granted thats a should 17:57:22 Ok … so voting on https://fedoraproject.org/wiki/User:Toshio/RubyPackagingDraft … with the section on "Provides" removed? 17:57:57 not the entire section just the bit about 'rubygems' requiring to provide ruby() 17:58:14 No … the entire section. 17:58:44 abadger1999: Right? 17:58:47 Indeed; I see nothing in that section that should stay if we jettison the virtual provides stuff. 17:58:49 The whole Dependencies section should o I think. 17:58:57 *should go 17:59:10 Oh, yeh … the requires are just about using the provides … so, yeh. 17:59:20 right 17:59:52 Oh, the ruby(abi) thing isn't in the Dependencies section at all. Odd, but sure, dump the whole thing. 18:00:05 Yeh 18:00:10 So, I'm +1. 18:00:26 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 ya it makes sense, essentially amounts to what we have now, just no syntax w/ the () 18:01:25 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 Page updated: https://fedoraproject.org/wiki/User:Toshio/RubyPackagingDraft 18:02:01 abadger1999: two more small things if I may 18:02:03 it will be a bit of work updating all the packages but again not a blocker there 18:02:09 and it does simplify things in the long run 18:02:21 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 abadger1999: not rubygem(rspec-core) 18:03:03 abadger1999: and without the virtual provides of course 18:03:11 bkabrda: Which will now be rubygem-rspec … right? 18:03:12 ah ya good catch 18:03:13 * geppetto nods 18:03:17 geppetto: right 18:03:30 Ok, seems fine. 18:03:32 What's the other thing? 18:03:48 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 Updated: "To run tests using RSpec >= 2 you must BuildRequires: rubygem-rspec and use something like: " 18:04:36 because sometimes the developers really put the restrictions for a reason (not so often, but they do) 18:04:54 bkabrda: Well it already says "but we know that a different version will also work" 18:05:09 But if you have alternate wording, that seems fine. 18:05:16 geppetto: I was just thinking more explicit would be better 18:05:22 yeh tend to like leaving it as is myself 18:05:37 afterall the guidelines already say a reviewer should test the package 18:05:50 but nbd either way 18:06:43 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 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 abadger1999: yes, that's very good 18:07:17 +1 18:07:46 abadger1999: And another rubgygem(minitest) in the MiniTest section. 18:08:04 And rubygem(test-unit). 18:08:16 That's it, AFAICS. 18:08:47 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 *new packages => packages 18:09:06 * limburgher is back 18:09:41 Ok, with those changes … I'm +1 again. 18:10:27 Okay, those changes all made 18:10:53 I'm fine with a transition. 18:11:20 no problems on my side 18:11:27 FPC doesn't generally mandate any retroactive changes anyway. 18:11:42 mmorsi, bkabrda: Did the things that need to be changedin https://fedoraproject.org/wiki/User:Toshio/RubyPackagingDraft#Some_notes 18:11:47 seem complete and okay? 18:12:11 tibbs|h: now u tell us :-p 18:12:45 yeh the alternative interpreters situation needs to be figured out 18:13:01 until then we can just go w/ the current draft, dropping those notes 18:13:16 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 as soon as we have more info regarding that, we'll get back to ya'll w/ more info 18:13:57 bkabrda: well... that was part of the "vendordir-is-interpreter-independent" discussion... probably a minor branch off of it. 18:14:13 Minor question: the sections near the end, "To run tests using *". How do I know which is required? 18:14:43 tibbs|h: from Rakefile 18:14:48 hrm well for rspec there will usually be a 'specs' dir 18:15:01 or a 'spec' dir 18:15:08 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 *specialcasing 18:15:30 honestly not sure about test unit / minitest 18:15:43 might just be a per-project thing 18:15:59 or like bkabrda said the rakefile will be biggest indication 18:16:00 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 understood 18:16:12 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 ya check the rakefile, thats your best bet 18:16:28 bkabrda: I'm still somewhat against special-casing. What do we gain by specialcasing rubygems in this way? 18:16:37 either 'minitest' or 'unit' or 'rspec' will be included there 18:16:53 (in the vast majority cases, eg all the ones i've seen) 18:17:57 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 gem expects certain things about the gems path to work too 18:19:43 bkabrda: why can't we have that and still have the rubygems module live in the vendorlibs/per-interpreter-stdlibs? 18:21:17 (note rubygems packages would live in /usr/share/rubygems... just the rubygem module would be in the per-interpreter area) 18:21:26 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 abadger1999: yes, I understand that 18:23:16 The gem command is run by a ruby interpreter? Then it'll use the rubygem module associated with that interpreter. 18:23:34 The CVE argument applies to anything in vendorlib, though. 18:23:54 which we've already decided is not desirable to share between ruby interpreters. 18:23:57 abadger1999: the gem command is run just like that. it has a shebang 18:24:37 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 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 especially since it's not there yet and requires work by us to enable? 18:28:02 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 bkabrda: okay... but there's non-gem modules that are shareable now. So shouldn't we be prioritising those? 18:29:02 abadger1999: no, because these are not so heavily used 18:30:23 * SmootherFrOgZ has to run for a few minutes. 18:30:33 okay -- so the deciding factor is whether we should specialcase rubygems because they are heavily used. 18:30:35 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 abadger1999: mostly. yes 18:31:43 but as I said, having one "gem" command is a huge advantage, for example 18:32:16 arg wireless died 18:32:35 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 abadger1999: you have gem and jgem for instance 18:33:36 (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 otherwise you have a jruby system that drags in ruby just so the gem command works. 18:34:19 bkabrda: But if the backend is neutral, in packaging you simply %exclude %{_bindir}jgem 18:34:31 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 bkabrda: right -- I'm saying that the shebang doesn't work when you do that. 18:35:42 abadger1999: stripping jgem will prevent users from using jrubygems - and any gems with jruby for that matter 18:36:13 why? ruby calls out to the %{_bindir} script in order to use gems? 18:37:19 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 because it won't know how to compile jars 18:38:06 bkabrda: okay. So then for now you must have jgem installed. 18:38:15 abadger1999: for now, yes 18:38:40 which means that we should not be special casing rubygems. 18:38:49 we need two separate implementations. 18:38:57 what is the problem in taking this step by step? 18:39:31 probably that we don't know what the steps are :-) 18:39:43 I should be in another meeting now. 18:39:44 1) take rubygems out of MRI ruby 18:39:54 srry if i missed anything but gem requires the directory structure to be setup the way it is 18:39:59 2) make them work with both Jruby and MRI ruby 18:40:12 So we probably need to stop this meeting and continue this paricular portion of the discussion later. 18:40:22 first step is done, second will be 18:40:42 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 Seems better to do them in the other order. 18:41:03 I don't really see why 18:41:45 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 so I can't evaluate. 18:42:03 we thought we would make that into F17, we didn't. 18:42:18 but why would we revert half of the work? 18:42:40 it will get there, it just needs a bit more time 18:42:59 why would you start work by making the "finalize this" type of change? 18:43:07 anyway... 18:43:18 We're well over time 18:43:37 ok, so I guess we'll discuss this on the list 18:43:42 Thanks 18:43:44 #endmeeting