16:58:59 <spot> #startmeeting Fedora Packaging Committee
16:58:59 <zodbot> 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 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:59:01 <spot> #meetingname fpc
16:59:01 <zodbot> The meeting name has been set to 'fpc'
16:59:07 <spot> #topic Roll Call
16:59:27 * limburgher here
16:59:31 * j_dulaney guesses this isn't Go-NoGo
16:59:38 <j_dulaney> Wrong channel
17:00:45 * abadger1999 here
17:00:52 <spot> rdieter, Smoother1rOgZ, tibbs: ping
17:01:48 <rdieter> hola
17:02:29 <spot> geppetto: ping
17:03:25 * geppetto is here
17:03:37 <spot> hey, that's quorum!
17:03:43 <tibbs> Ugh.
17:03:51 <tibbs> Getting over the flu.
17:03:59 <limburgher> Ooo. Sorry.
17:04:01 <spot> tibbs: sorry to hear that.
17:04:21 <spot> #topic Vote on sagemath exception proposal : https://fedorahosted.org/fpc/ticket/238
17:04:43 <spot> the ticket got +4, (rdieter, abadger, limburgher, and spot)
17:04:47 <tibbs> +1
17:04:57 <spot> okay, that makes it +5
17:05:10 <tibbs> Sorry, I should have voted in the ticket.
17:06:09 <spot> #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 <spot> Okay, I have one other item on today's agenda
17:07:34 <spot> #topic Add a criteria for a general multilib exception - https://fedorahosted.org/fpc/ticket/240
17:09:02 <rdieter> good 'ol ralf
17:09:16 <spot> yep.
17:09:25 <rdieter> anyway, I'm +1 to the proposal
17:09:37 <abadger1999> +1
17:09:41 <geppetto> I'm not sure I understand … what does saying stuff in libexecdir is multilib (or not) do?
17:10:17 <spot> geppetto: since %{_libexecdir} is identical in all multilib scenarios
17:10:29 <spot> geppetto: if binaries are in there, the package _cant_ be multilib
17:10:52 <tibbs> +1
17:10:56 <abadger1999> geppetto: So before, we basically said: If a package is exempt from multilib, it may use <code>%{_prefix}/lib</code> instead of <code>%{_libdir}</code>.   Ask FESCo if your package is exempt from multilib.
17:10:57 <limburgher> +1
17:11:16 <geppetto> 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 <abadger1999> 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 <geppetto> 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 <abadger1999> 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 <spot> 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 <abadger1999> <nod>
17:13:58 <geppetto> Ok, I'm +1
17:14:30 <geppetto> I guess it just seemed obvious to me...
17:14:37 <spot> I think perhaps doing s|Helper binaries that|Packages that contain architecture specific helper binaries that|g
17:15:16 <geppetto> I would change the word "exempt" to something else too.
17:15:38 <geppetto> Maybe "ineligible" ?
17:16:11 <abadger1999> 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 <geppetto> Maybe "multilib is automatically disabled"
17:17:45 <abadger1999> How broad do we want this?
17:18:19 <spot> 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 <abadger1999> would we consider noarch packages to be covered?  Are they "multilib is automatically disabled"?
17:18:44 <spot> noarch packages should be installable on any arch.
17:19:00 <spot> i don't want to think about how you'd have a multilib noarch packages.
17:19:06 <spot> s/a/any
17:19:59 <geppetto> :)
17:20:08 <abadger1999> yeah -- so noarch packages cannot use %{_libdir} at all.
17:20:14 <abadger1999> anyhow, +1 to spot's wording.
17:20:49 <spot> +1 to the draft with my wording change
17:21:05 <geppetto> 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 <geppetto> But I often fail at English grammar, so if it looks correct to others ignore me :)
17:22:04 <rdieter> +1
17:22:20 <spot> my brain says "does not" is correct. it parse errors at "do not". but it could be wrong.
17:22:36 <tibbs> "does not" appears correct to me.
17:22:38 <tibbs> Anyway, +1.
17:23:11 <spot> that's +5
17:23:15 <spot> limburgher: still +1?
17:23:22 <limburgher> YEs.
17:23:27 <limburgher> +1
17:23:27 <spot> okay. +6.
17:23:48 <spot> #action Slightly reworded version of abadger1999's proposal approved (+1:6, 0:0, -1:1)
17:25:19 <spot> thats all i had on today's agenda
17:25:22 <spot> so open floor time
17:25:25 <spot> #topic Open Floor
17:25:35 <abadger1999> Ruby :-/
17:25:43 <geppetto> close the floor!
17:25:52 <spot> i don't see a ticket for Ruby
17:26:15 <abadger1999> Yeah -- but it's being discussed in packaging list
17:26:30 <abadger1999> This is a heads up that it's on its way
17:26:40 <tibbs> It just gets worse, I guess.
17:27:07 <abadger1999> 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 <abadger1999> it's split over two threads.
17:27:45 <abadger1999> Main thread: http://lists.fedoraproject.org/pipermail/packaging/2013-January/008842.html
17:27:52 <abadger1999> Other thread: http://lists.fedoraproject.org/pipermail/packaging/2013-January/008843.html
17:28:42 * spot will wait for a draft. :/
17:29:38 <abadger1999> Do we want non-versioned virtual requirements?
17:29:54 <abadger1999> If we don't, I think we really should say so in that thread.
17:30:11 <abadger1999> otherwise they're going to build up a large draft based around that concept.
17:30:31 <geppetto> Well we have them for things like MTA etc.
17:30:34 <abadger1999> Also -- do we want to support having different interpreters that are not 100% compatible
17:30:41 <geppetto> So it depends on what they are doing with them.
17:30:50 <tibbs> Right, in general, non-versioned virtual deps are OK.
17:30:51 <abadger1999> that are using the same library module packages.
17:30:57 <abadger1999> I think those are the two things.
17:31:14 * Smoother1rOgZ here
17:31:22 <abadger1999> In general, for language virtual provides, though -- they are required to be versioned (atm)
17:31:29 <geppetto> abadger1999: From what I understand David's long term goals are to do the same thing for python, right?
17:32:02 <abadger1999> geppetto: I don't think so to the same extent.
17:32:04 <spot> 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 <spot> Not sure how they'd pull that off without some sort of versioned Provides though.
17:32:18 <abadger1999> ie: I haven't heard anything about dropping the python(abi) = version requirement
17:32:35 <abadger1999> but he has talked about ways to utilize the existing python modules stack for pypy.
17:32:46 <abadger1999> so there may be half-overlap here.
17:32:55 <abadger1999> also -- I haven't heard anything about implementation
17:33:17 <abadger1999> Which could be key.... I mentioned a different way of implementing this in the thread but they didn't like it.
17:34:02 <spot> abadger1999: also, vit's most recent post says that the provide would be versioned
17:34:12 <abadger1999> spot: <nod>  but not the Requires.
17:34:15 <abadger1999> which is the key.
17:34:18 <spot> and the require would be versioned if necessary.
17:34:55 <spot> 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 <abadger1999> he says perl is the closest.  But perl is a Requires on the version of perl that it is built with.
17:35:03 <spot> This may be the exception rather than the rule, but still.
17:35:25 <abadger1999> Then the perl package is responsible for providing Virtual Provides declaring what previous versions it is compatible with.
17:35:51 <abadger1999> Which would work here except:
17:35:57 <spot> 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 <abadger1999> they also want jython to provide the virtual provides.
17:36:22 <spot> abadger1999: yeah. i see that.
17:36:22 <abadger1999> and no version of jython is 100% compatible with any version of cruby.
17:36:33 <abadger1999> so.. the model breaks down at that point :-(
17:36:35 <limburgher> No, I'd imagine not.
17:36:40 <spot> then that isn't a proper use of the provide/requires pairing
17:36:51 <abadger1999> 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 <abadger1999> 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 <abadger1999> I think I'd be okay with doing that outside of Requires and Provides.
17:38:32 <abadger1999> but virtual provides seems like a bad way to manage it.
17:39:02 <spot> I would say that perhaps having a "ruby(universal)" provide that both cruby and jython included
17:39:17 <spot> then, if a package was truly universal capable, it could Require that
17:39:24 <geppetto> abadger1999: how else would you do it?
17:39:27 <abadger1999> spot: unversioned?
17:39:51 <spot> abadger1999: well. the question becomes "does this work with any version of cruby or jython"?
17:40:07 <spot> if the answer is "no, only cruby >= 2.0 and jython >= 1.45"
17:40:15 <spot> then it couldn't be unversioned
17:40:32 <spot> we'd have to be clever, come up with some sort of ABI tracking
17:40:43 <spot> that road may lead to madness though.
17:40:48 <geppetto> Well more Application Language Interface
17:40:54 <geppetto> or something
17:41:00 <spot> (then again, i might posit that Ruby is what the road to madness is paved with)
17:41:17 <geppetto> no comment
17:41:23 <spot> geppetto: yeah, ABI is not the right wording, but you get the idea.
17:41:23 <abadger1999> 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 <spot> 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 <limburgher> 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 <abadger1999> 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 <abadger1999> (and byte compiled, etc)
17:42:52 * geppetto nods
17:43:04 <abadger1999> something similar to that makes more sense to me atm.
17:43:53 <geppetto> 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 <tibbs> Sounds like perl(:MODULE_COMPAT_whatever)
17:44:11 <limburgher> geppetto:  <nods to the point of dizziness>
17:44:11 <geppetto> anyway … as spot said, there's no proposal.
17:44:26 <spot> geppetto: yeah. and i'd rather not give myself a migraine until we see one.
17:44:27 <abadger1999> 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 <spot> please keep in mind there is a language barrier in play here.
17:44:59 <spot> so try to be extra clear and simple with your English. :)
17:45:37 <spot> okay. i'm hungry. so i'm calling this one done.
17:45:38 <spot> thanks everyone.
17:45:45 <limburgher> Sounds good.  Thanks!
17:45:46 <spot> #endmeeting