16:02:24 <abadger1999> #startmeeting
16:02:24 <zodbot> Meeting started Thu Jun 19 16:02:24 2014 UTC.  The chair is abadger1999. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:02:24 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:02:27 <abadger1999> #meetingname fpc
16:02:27 <zodbot> The meeting name has been set to 'fpc'
16:02:32 <abadger1999> #topic Roll Call
16:02:39 <abadger1999> #chair geppetto RemiFedora
16:02:39 <zodbot> Current chairs: RemiFedora abadger1999 geppetto
16:03:07 <abadger1999> spot, tibbs, SmootherFrOgZ: FPC ping
16:04:32 <abadger1999> #topic #topic #339     software collections in Fedora
16:04:55 <abadger1999> Since there's a few things to say about this... let's talk about it while waiting for quorum to show up
16:05:04 <abadger1999> So Remi and I have been talking about scldevel.
16:05:30 * geppetto nods
16:06:37 <abadger1999> What we know is that: macros should be provided in a namespaced form by the scl-version of the package that normally provides them (ie: fdr-python2.4-python-devel would provide %python2_sitelib
16:07:14 <abadger1999> These must also be pushed into the $scl-build package in a form that overrides the system macros.
16:07:54 <abadger1999> example: fdr-python2.4-python-devel has a %{_macrosdir}/macros.fdr-python2.4-python2  that has
16:08:54 <abadger1999> %python2_sitelib /opt/fedora/scls/fdr-python2.4/root/usr/lib/python2.7/site-packages
16:09:12 <abadger1999> err actually.
16:09:32 <abadger1999> RemiFedora: does this work in the -build package?
16:09:59 <abadger1999> %python2_sitelib %fdr_python2.4_python2_sitelib
16:10:04 <RemiFedora> yes
16:10:05 <abadger1999> Or does that have to be expanded form?
16:10:07 <abadger1999> okay
16:10:13 <abadger1999> so I messed up that last example
16:10:13 <RemiFedora> using the overrides function
16:10:42 <abadger1999> fdr-python2.4-python-devel has a %{_macrosdir}/macros.fdr-python2.4-python2   contains %fdr_python2.4_python2_sitelib /opt/fedora/scls/fdr-python2.4/root/usr/lib/python2.7/site-packages
16:11:27 <abadger1999> fdr-python2.4-build has a %{_macrosdir}/macros.fdr-python2.4  that contains  %python2_sitelib %fdr_python2.4_python2_sitelib
16:11:46 <abadger1999> There may be an intermediate step if the scl owners want to provide it.
16:12:07 <abadger1999> The intermediate step is an scldevel subpackage.  It's purpsoe is to make it easier to port a package between scls.
16:12:44 <abadger1999> It defines macros that do not conflict with system macros but will ocnflict with other scls that serve a similar purpose (example other python versions)
16:12:54 <abadger1999> So the -scdevel would look like this:
16:13:18 <abadger1999> %{_macrosdir}/macros.fdr-python2.4-scldevel that contains %python2_sitelib %fdr_python2.4_python2_sitelib
16:13:24 <abadger1999> and -build would look like this:
16:13:41 <abadger1999> ugh
16:13:43 <abadger1999> Messed up again
16:13:48 <abadger1999> So the -scdevel would look like this:
16:14:06 <abadger1999> %{_macrosdir}/macros.fdr-python2.4-scldevel that contains   %scl_python2_sitelib %fdr_python2.4_python2_sitelib
16:14:18 <abadger1999> and -build would look like this:
16:14:39 <abadger1999> %{_macrosdir}/macros.fdr-python2.4 that contains %python2_sitelib %scl_python2_sitelib
16:15:07 <RemiFedora> hmmmm
16:15:11 <geppetto> ok
16:15:39 <geppetto> the first part I understand (although you need to s/[.]/_/) … the 2nd, I think I understand.
16:15:45 <abadger1999> Then if the owners of the python2.7 scl and the python2.4 scl coordinate their generic macro names, someone creating an scl package that could be built for both will not have to change their macros (they use %scl_python2_sitelib for both)
16:15:50 <geppetto> But I'm very dubious of the utility.
16:16:17 <RemiFedora> more complexity to allow more generic spec file...
16:16:24 <abadger1999> <nod>  I don't think this is very useful in Fedora.. but it may be useful for others.
16:16:56 <abadger1999> there's a few problems:
16:18:17 <abadger1999> 1) The macro file needs to be in the buildroot before SRPM creation time.  So this means releng will need to configure a new target for it.  This isn't really restricted to scldevel though.  So it's better to make a generic rule about scl packages that require more than one SCL.
16:19:35 <abadger1999> Something like: No SCL packages can require more than one SCL.  If your package needs more than one SCL to function, you must have a new SCL that requires the other SCLs and your package will only require this new SCL.
16:20:22 <abadger1999> 2) Centralized vs decentralized.  There's two aspects to this:
16:20:58 <abadger1999> A) fdr-python2.7-scldevel is maintained by a single maintainance team.  The fdr-python2.4-scldevel team may be different.
16:21:14 <abadger1999> The two teams ned to coordinate to make the generic macro names useful
16:22:23 <abadger1999> B) People adding packages to the fdr-python2.7 SCL may not be a part of the team maintaining the scldevel package.  If they add a package that adds macros, there's a two way communication problem.
16:22:44 <abadger1999> they may be blocked on the scldevel team adding their generic macros to the scldevel package.
16:23:13 <abadger1999> The scldevel team may not want -scldevel and -build packages becoming dependent on this "third-party" package.
16:23:40 <abadger1999> So that's the background of what RemiFedora and I talked about.
16:24:03 <abadger1999> geppetto: Does all of that background make sense?
16:25:46 <geppetto> I understand … kind of … but my first reaction to all of this is "no, just copy and paste some stuff … organizing the collaboration is going to take at least as much time as you'll waste on copy and paste"
16:26:10 <abadger1999> Yeah -- so options:
16:26:37 <abadger1999> Ban the scldevel strategy... as you say, this is just too complex compared to just copy paste, and slightly modify macro names.
16:27:12 <geppetto> And also I'm not so hot on the whole "Q. what does the srpm do … A. well it depends on how you build it, or how you rebuild the srpm itself"
16:28:33 <abadger1999> Only use generic macros for packages in the SCL-owner controlled packages: this eliminates the problem between the scl owners and people packaging for the scl but doesn't eliminate the problem between scl owner of python2.7 and scl owner of python2.4
16:29:25 <abadger1999> Allow it but make it optional for both sides.  SCL Owners do not have to provide an scldevel package.  SCL Users do not have to use the generic macros provided by an scldevel package.
16:30:13 <abadger1999> I think that only banning it would address the "The SRPM builds differently depending on the environment the rpm is built in".
16:31:18 <geppetto> "Allow it but make it optional for both sides.  SCL Owners do not have to provide an scldevel package.  SCL Users do not have to use the generic macros provided by an scldevel package." … I don't think I mind this.
16:31:28 <geppetto> At least I could +1 and see what happens.
16:31:38 <abadger1999> We did decide that we wanted separate spec files so that we didn't have to deal with SPRM building differently in different environments... although we haven't decided that we'd ban the conditional syntax...
16:32:00 <abadger1999> <nod>  I could +1 that as well.
16:32:11 <abadger1999> and I think RemiFedora said he could +1 it too.
16:32:15 <RemiFedora> yes
16:33:35 <abadger1999> Cool.  So we don't have quorum but for the people present we do have consensus that this direction is okay.
16:33:57 <abadger1999> I'll work on figuring out where to add it to the page and also add an explanation of the purpose of the scldevel package.
16:34:40 <abadger1999> Still no quorum so...
16:34:43 <abadger1999> #topic Open Floor
16:35:14 <abadger1999> Anything people want to bring up?
16:35:16 <abadger1999> are there people present who want us to discuss and start voting on a ticket?
16:36:09 <abadger1999> #info shiboken bundled code: https://fedorahosted.org/fpc/ticket/436 passed in ticket (+1:5, 0:0, -1:0)
16:36:54 <abadger1999> langdon: You around?
16:37:07 <abadger1999> langdon: Anything to say about the Ruby SCL ticket/naming if so?
16:38:05 <abadger1999> RemiFedora, geppetto: So the set of ruby, v8, rails scls do have an interdependency that we need to resolve the cornercase naming for.
16:38:17 <abadger1999> ruby is standalon.  v8 is standalone.
16:38:27 <abadger1999> rails requires both the ruby scl and the v8 scl.
16:38:40 <abadger1999> How should the rails scl be named?
16:40:58 <RemiFedora> could we imagine 2 rails SCL (same version) using different ruby verions ?
16:41:23 <abadger1999> RemiFedora: yeah, or one of them not using v8.  Or using a different version of v8.
16:41:34 <geppetto> yeh
16:45:29 <RemiFedora> fdr-rail4.0-using-ruby2.1-with-v8_3.1-is-an-awfull-name
16:46:00 <abadger1999> RemiFedora: Yeah, that's exactly the predicament I'm in too.
16:46:39 <geppetto> yeh
16:46:43 <geppetto> but … it is what it is
16:47:17 <geppetto> personally I'd argue that it should be fdr-rail4.0 … and it'd "bundle" the ruby and v8 within the scl
16:47:34 <geppetto> Or mysql/pgsql/whatever … that it needs.
16:48:00 <geppetto> But if we are going the inter scl deps. way … then it has to be names from hell.
16:51:13 <abadger1999> I suppose for rails we could invoke the "there can be only one" rule. https://fedoraproject.org/wiki/User:Toshio/SCL_Guidelines_(draft)#There_can_be_only_one
16:51:36 <abadger1999> Does that seem like it limits the abilities of SCLs too much or is it okay?
16:52:18 <RemiFedora> probably ok for now
16:52:47 <RemiFedora> and if at some time someone need 2 scl of same framework, and comes with a nice proposal, we can change the Guidelines....
16:52:50 <abadger1999> It would mean you oculd never have another rails4.0 scl (so no rails with a different ruby version or a different v8 version...)
16:53:01 <RemiFedora> yes
16:53:04 <abadger1999> RemiFedora: <nod> -- except... naming/renaming.
16:53:26 <abadger1999> I guess it could be grandfathered.
16:55:09 <abadger1999> RemiFedora: I mean -- to take php as an example, would you be okay if we provided an httpd2.4 httpd2.5 httpd2.6  but if you wanted to use php2.7 you could only run it with httpd2.5?
16:56:11 <abadger1999> Perhaps this is thorny enough that we should just think on the ramifications for a week and then figure out our direction next week.
16:56:44 <abadger1999> Anything else people want to discuss?
16:56:48 <geppetto> yeh, that isn't going to fly
16:56:53 <geppetto> at least in general, IMO
16:56:59 <abadger1999> Yeah.
16:57:24 <abadger1999> Okay, I'll close in 60s
16:59:24 <abadger1999> #endmeeting