16:58:59 #startmeeting Fedora Packaging Committee 16:58:59 Meeting started Wed Jan 9 16:58:59 2013 UTC. The chair is spot. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:58:59 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:59:01 #meetingname fpc 16:59:01 The meeting name has been set to 'fpc' 16:59:07 #topic Roll Call 16:59:27 * limburgher here 16:59:31 * j_dulaney guesses this isn't Go-NoGo 16:59:38 Wrong channel 17:00:45 * abadger1999 here 17:00:52 rdieter, Smoother1rOgZ, tibbs: ping 17:01:48 hola 17:02:29 geppetto: ping 17:03:25 * geppetto is here 17:03:37 hey, that's quorum! 17:03:43 Ugh. 17:03:51 Getting over the flu. 17:03:59 Ooo. Sorry. 17:04:01 tibbs: sorry to hear that. 17:04:21 #topic Vote on sagemath exception proposal : https://fedorahosted.org/fpc/ticket/238 17:04:43 the ticket got +4, (rdieter, abadger, limburgher, and spot) 17:04:47 +1 17:04:57 okay, that makes it +5 17:05:10 Sorry, I should have voted in the ticket. 17:06:09 #action No exception for cython (coordination with system cython should be sufficient), Temp (6month) exception for ipython, no exception for pexpect, unless it is impossible to fixup system pexpect for sagemath's use: (+1:5, 0:0, -1:0) 17:07:21 Okay, I have one other item on today's agenda 17:07:34 #topic Add a criteria for a general multilib exception - https://fedorahosted.org/fpc/ticket/240 17:09:02 good 'ol ralf 17:09:16 yep. 17:09:25 anyway, I'm +1 to the proposal 17:09:37 +1 17:09:41 I'm not sure I understand … what does saying stuff in libexecdir is multilib (or not) do? 17:10:17 geppetto: since %{_libexecdir} is identical in all multilib scenarios 17:10:29 geppetto: if binaries are in there, the package _cant_ be multilib 17:10:52 +1 17:10:56 geppetto: So before, we basically said: If a package is exempt from multilib, it may use %{_prefix}/lib instead of %{_libdir}. Ask FESCo if your package is exempt from multilib. 17:10:57 +1 17:11:16 Kind of … but what does that mean? I mean why are we saying that explicitly in the policy, how does it help a packager? 17:11:34 geppetto: This is adding one class of packages that packagers don't need to go to fesco to ask if it's exempt (because it should always be so). 17:11:52 Is the text trying to say: If you put anything in libexecdir then you can't have a .i686 and .x86_64 package installed at once, so don't do that? 17:12:44 not really -- it's more trying to define one class of multilib exempt packages so that packagers don't have to go to fesco. 17:12:58 I think it is trying to say: If your package has architecture specific binaries in %{_libexecdir}, it is considered exempt from multilib. 17:13:03 17:13:58 Ok, I'm +1 17:14:30 I guess it just seemed obvious to me... 17:14:37 I think perhaps doing s|Helper binaries that|Packages that contain architecture specific helper binaries that|g 17:15:16 I would change the word "exempt" to something else too. 17:15:38 Maybe "ineligible" ? 17:16:11 That works for me. Suddenly I wonder about shell/python/etc scripts but I think I'll choose to ignore that for now :-) 17:16:12 Maybe "multilib is automatically disabled" 17:17:45 How broad do we want this? 17:18:19 Okay. Maybe "Packages that contain architecture specific files that would ordinarily be installed into %{_libexecdir} are always considered ineligible for multilib. However, you should be sure that the (sub)package that they are in does not have other content that would be considered eligible for multilib. 17:18:28 would we consider noarch packages to be covered? Are they "multilib is automatically disabled"? 17:18:44 noarch packages should be installable on any arch. 17:19:00 i don't want to think about how you'd have a multilib noarch packages. 17:19:06 s/a/any 17:19:59 :) 17:20:08 yeah -- so noarch packages cannot use %{_libdir} at all. 17:20:14 anyhow, +1 to spot's wording. 17:20:49 +1 to the draft with my wording change 17:21:05 I'm +1 on spot's rewording … but I'm not sure if "the (sub)package that they are in does not have" should be "the (sub)package that they are in do not have" (does => do) 17:21:30 But I often fail at English grammar, so if it looks correct to others ignore me :) 17:22:04 +1 17:22:20 my brain says "does not" is correct. it parse errors at "do not". but it could be wrong. 17:22:36 "does not" appears correct to me. 17:22:38 Anyway, +1. 17:23:11 that's +5 17:23:15 limburgher: still +1? 17:23:22 YEs. 17:23:27 +1 17:23:27 okay. +6. 17:23:48 #action Slightly reworded version of abadger1999's proposal approved (+1:6, 0:0, -1:1) 17:25:19 thats all i had on today's agenda 17:25:22 so open floor time 17:25:25 #topic Open Floor 17:25:35 Ruby :-/ 17:25:43 close the floor! 17:25:52 i don't see a ticket for Ruby 17:26:15 Yeah -- but it's being discussed in packaging list 17:26:30 This is a heads up that it's on its way 17:26:40 It just gets worse, I guess. 17:27:07 and also a reqeust that people wiegh in on the thread because there's some things that they're wanting to do pretty badly that I'm not sure we want to allow. 17:27:18 * abadger1999 gets mailing list link 17:27:43 it's split over two threads. 17:27:45 Main thread: http://lists.fedoraproject.org/pipermail/packaging/2013-January/008842.html 17:27:52 Other thread: http://lists.fedoraproject.org/pipermail/packaging/2013-January/008843.html 17:28:42 * spot will wait for a draft. :/ 17:29:38 Do we want non-versioned virtual requirements? 17:29:54 If we don't, I think we really should say so in that thread. 17:30:11 otherwise they're going to build up a large draft based around that concept. 17:30:31 Well we have them for things like MTA etc. 17:30:34 Also -- do we want to support having different interpreters that are not 100% compatible 17:30:41 So it depends on what they are doing with them. 17:30:50 Right, in general, non-versioned virtual deps are OK. 17:30:51 that are using the same library module packages. 17:30:57 I think those are the two things. 17:31:14 * Smoother1rOgZ here 17:31:22 In general, for language virtual provides, though -- they are required to be versioned (atm) 17:31:29 abadger1999: From what I understand David's long term goals are to do the same thing for python, right? 17:32:02 geppetto: I don't think so to the same extent. 17:32:04 I think if they have a way to know if a module works with an interpreter (both type and version), via a Requires/Provides pair, then I'm not necessarily opposed to it. 17:32:15 Not sure how they'd pull that off without some sort of versioned Provides though. 17:32:18 ie: I haven't heard anything about dropping the python(abi) = version requirement 17:32:35 but he has talked about ways to utilize the existing python modules stack for pypy. 17:32:46 so there may be half-overlap here. 17:32:55 also -- I haven't heard anything about implementation 17:33:17 Which could be key.... I mentioned a different way of implementing this in the thread but they didn't like it. 17:34:02 abadger1999: also, vit's most recent post says that the provide would be versioned 17:34:12 spot: but not the Requires. 17:34:15 which is the key. 17:34:18 and the require would be versioned if necessary. 17:34:55 If ruby-foo works fine with any value of ruby(release), why would we force them to have a versioned Requires there? 17:35:01 he says perl is the closest. But perl is a Requires on the version of perl that it is built with. 17:35:03 This may be the exception rather than the rule, but still. 17:35:25 Then the perl package is responsible for providing Virtual Provides declaring what previous versions it is compatible with. 17:35:51 Which would work here except: 17:35:57 abadger1999: in the perl universe that makes more sense, since every perl package screams when run against a different interpreter than the one it was built against 17:36:05 they also want jython to provide the virtual provides. 17:36:22 abadger1999: yeah. i see that. 17:36:22 and no version of jython is 100% compatible with any version of cruby. 17:36:33 so.. the model breaks down at that point :-( 17:36:35 No, I'd imagine not. 17:36:40 then that isn't a proper use of the provide/requires pairing 17:36:51 yep. 17:37:31 * spot will see Vit in February, so i can try to talk about his ideas then, if a draft doesn't appear beforehand 17:37:47 their argument is that some subset (maybe large) of ruby code is compatible with both cruby and jython and they want to leverage that. 17:38:17 I think I'd be okay with doing that outside of Requires and Provides. 17:38:32 but virtual provides seems like a bad way to manage it. 17:39:02 I would say that perhaps having a "ruby(universal)" provide that both cruby and jython included 17:39:17 then, if a package was truly universal capable, it could Require that 17:39:24 abadger1999: how else would you do it? 17:39:27 spot: unversioned? 17:39:51 abadger1999: well. the question becomes "does this work with any version of cruby or jython"? 17:40:07 if the answer is "no, only cruby >= 2.0 and jython >= 1.45" 17:40:15 then it couldn't be unversioned 17:40:32 we'd have to be clever, come up with some sort of ABI tracking 17:40:43 that road may lead to madness though. 17:40:48 Well more Application Language Interface 17:40:54 or something 17:41:00 (then again, i might posit that Ruby is what the road to madness is paved with) 17:41:17 no comment 17:41:23 geppetto: yeah, ABI is not the right wording, but you get the idea. 17:41:23 yeah, and that's what I think we get into. (also, vit wnats to do this post-package release). ie: assume that all code is universal. when bugs are filed, update the package with a more specific require. 17:41:48 I don't think it is remotely safe to assume all code is universal when we know already that most is not. 17:42:15 And if it is, who says it will always be? 17:42:28 * spot would rather see interpreter specific subpackages than blanket assumptions like that 17:42:36 geppetto: So... for python. debian marks packages compatible with a set of python versions (2.5, 2.6, 2.7) separate from the package itself. Then on install, the modules are linked into the proper python library paths 17:42:42 (and byte compiled, etc) 17:42:52 * geppetto nods 17:43:04 something similar to that makes more sense to me atm. 17:43:53 I think a lot of the ruby problem is that they basically want to just use "gem install", and don't really understand the difference between something for developers and for users. 17:44:08 Sounds like perl(:MODULE_COMPAT_whatever) 17:44:11 geppetto: 17:44:11 anyway … as spot said, there's no proposal. 17:44:26 geppetto: yeah. and i'd rather not give myself a migraine until we see one. 17:44:27 anyhow -- please pay attention to the thread and weigh in so everyone gets an idea of what is going to be acceptable and what is not. 17:44:51 please keep in mind there is a language barrier in play here. 17:44:59 so try to be extra clear and simple with your English. :) 17:45:37 okay. i'm hungry. so i'm calling this one done. 17:45:38 thanks everyone. 17:45:45 Sounds good. Thanks! 17:45:46 #endmeeting