16:02:30 <abadger1999> #startmeeting fpc
16:02:30 <zodbot> Meeting started Thu Sep 26 16:02:30 2013 UTC.  The chair is abadger1999. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:02:30 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:02:36 <abadger1999> #topic Roll Call
16:02:39 * geppetto is here
16:02:49 <abadger1999> #chair abadger1999 geppetto
16:02:49 <zodbot> Current chairs: abadger1999 geppetto
16:03:04 <tibbs|w> Cheers.
16:03:36 <abadger1999> ping spot, RemiFedora, SmootherFrOgZ FPC meeting
16:03:52 * RemiFedora here
16:04:04 <abadger1999> #chair RemiFedora
16:04:04 <zodbot> Current chairs: RemiFedora abadger1999 geppetto
16:04:06 * samkottler is here
16:04:13 <abadger1999> #chair tibbs|w
16:04:13 <zodbot> Current chairs: RemiFedora abadger1999 geppetto tibbs|w
16:04:37 <abadger1999> Not enough for quorum yet... racor said he might not be able to make it to this week's meeting.
16:04:57 <abadger1999> We weren't going to get to a vote on scls anyow so it might not matter.
16:05:13 <abadger1999> bkabrda is here this week to answer technical questions.
16:05:27 <tibbs|w> Would be super nice if we could actually get to something else on the agenda as well.
16:05:30 <bkabrda> yep
16:06:05 <mattdm> tibbs|w vote yes and let's move on :)
16:06:15 <abadger1999> tibbs|w: yeah -- I think since we have bkabrda what we should do is tackle more scl stuff this week and then next week don't do any scl stuff at the meeting.
16:06:47 <samkottler> mattdm: amen
16:06:48 <abadger1999> #chair Rathann
16:06:48 <zodbot> Current chairs: Rathann RemiFedora abadger1999 geppetto tibbs|w
16:08:05 <abadger1999> #topic SCLs https://fedorahosted.org/fpc/ticket/339
16:08:41 <abadger1999> Few links to start us off: https://fedoraproject.org/wiki/User:Toshio/SCL_Guidelines_Q%26A   <= slowly adding to that -- I need to get bkabrda's replies on there.
16:09:03 <abadger1999> https://fedorahosted.org/fesco/ticket/1175 <= fesco ticket for our questoins last week
16:09:06 <abadger1999> fesco basically said,
16:09:10 <bkabrda> abadger1999: I tried to incorporate most of the comments into my guidelines draft
16:09:15 * SmootherFrOgZ is sort of here. (stuck in a meeting @dayjob)
16:09:19 <abadger1999> backwards compat guarantees can be decided per-scl.
16:09:30 <abadger1999> #chair SmootherFrOgZ
16:09:30 <zodbot> Current chairs: Rathann RemiFedora SmootherFrOgZ abadger1999 geppetto tibbs|w
16:10:12 <abadger1999> and can range fronm 0 backwards compat guarantee to 100% backwards compat.  The requirement is for the scl to document that.
16:10:33 <mattdm> So, humor me for a moment. If we grant (at least temporarily) that 1) there are valid Fedora use cases, 2) that it's okay to try some things even though we know they're not perfect, and 3) we know that the guidelines need some detail work, what _technical_ objections remain, and how can we fix those?
16:13:09 <abadger1999> 1) thick or thin (I'm now thinking both depending on the extent of backwards compat guarantees).
16:13:17 <abadger1999> 2) Criteria for approing an scl
16:13:33 <abadger1999> 3) naming -- what prefix?  what form for the version?
16:13:33 <geppetto> Have we established #1 or #2 ? … but assuming those were true, I think the main technical problems are to do with how/where the SCLs get installed (Esp. good would be if the locations for Fedora supplied and 3rd party supplied were different).
16:13:47 <abadger1999> 4) Where do things get installed?
16:14:33 <mattdm> abadger1999 I think I would categorize all of those as "guidelines detail work".
16:14:49 <mattdm> geppetto do you mean 'where in the filesystem' or 'from what repository'?
16:14:49 <geppetto> And, yeh, abadger1999's #2 is the main other thing for me … how do SCLs get into the distro.
16:15:18 <abadger1999> 5) Separate packages or separate branches?  And how many packages/branches do we need (I think for each package in an scl we have to be able to build the package separately for each release-of-fedora x scl-that-package-is-in combination)
16:15:20 <geppetto> mattdm: Presumably if we approve them they'll be in the fedora/updates repos. … otherwise they aren't Fedora.
16:15:50 <mattdm> geppetto so then it's a matter of /opt vs. /usr/lib/scl vs. whatever?
16:15:57 <abadger1999> mattdm: isn't that what you asked me to list?  The things that are technical decisions we need to make?
16:16:01 <bkabrda> geppetto: I liked the idea of having SCL Sig, that would review them, but I guess Changes approved by FESCo would work as well
16:16:01 <geppetto> mattdm: Right.
16:16:19 <RemiFedora> +1 for a SCL SIG
16:16:31 <abadger1999> I'm going to talk wit dgilmore next week about how building scls might look so I think #5 can be discussed then.
16:16:42 <abadger1999> -1 to SCL SIG.  and -1 to FESCo.
16:16:44 <RemiFedora> (not for SCL approval, but for documentation, help, ...)
16:16:45 <mattdm> abadger1999 I'm making a distinction between a general "SCLs are okay for some cases" and the specific rules for implementation
16:17:03 <geppetto> abadger1999: What would you prefer to SCL SIG?
16:17:17 <abadger1999> But we could talk about the Environments and Stack WG.
16:17:23 <mattdm> Environments and Stacks Working Group as part of Fedora.next proposal
16:17:33 <mattdm> right abadger1999 :)
16:17:36 <abadger1999> Yeah.
16:18:21 <abadger1999> RemiFedora: ah, yeah, for documentation and help that would be fine.
16:18:36 <bkabrda> abadger1999: mattdm: you this WG would approve SCLs?
16:18:41 <bkabrda> *you mean
16:18:55 <mattdm> back to the bigger question: there's a distinction between deciding "should I redo the electrical in my house" and "where do the outlets go, which amperage breakers to use, do i want to pay the electrician to install the ceiling fan..."
16:19:41 <abadger1999> bkabrda: yea.  I think I posted in the ticket why I don't like fesco or a sig... if not, it's also in an email I just sent to the lsit.
16:19:56 <mattdm> Right now I feel like we're kind of in the point where discussing the ceiling fan part is obscuring the question which needs to come first
16:20:10 <bkabrda> abadger1999: ok, that sounds good
16:20:11 <mattdm> even though i am all for making sure that the details actually work
16:20:13 <abadger1999> mattdm: Well, what's should I redo the electrical in my house?
16:20:33 <abadger1999> In this case?
16:20:51 * abadger1999 also would like to make sure that we make good use of bkabrda's time today :-)
16:20:53 <mattdm> abadger1999 one sec
16:20:58 <samkottler> I think it's actually important for language SIG's to maintain their SCL's
16:21:15 <bkabrda> we're reconstructing the whole house with Fedora.next, so why not redo the electrical while at it ;)
16:21:34 <geppetto> samkottler: So the only people who are allowed to create an SCL that includes ruby would need to be on the ruby SIG?
16:21:59 <mattdm> In the current packaging guidelines, there's a line which says "Software Collections (as defined here) are not permitted to be built or enabled in official Fedora packages." I'd like to propose replacing that line with "SCLs can exist within Fedora within a certain set of guidelines. Those guidelines are in progress."
16:22:07 <geppetto> bkabrda: Right, that's part of the problem … the question is should we redo the electrical in the house, and we aren't all talking about the same house.
16:22:13 <abadger1999> samkottler: SIGs are pretty loose to be able to make that a requirement.
16:22:53 <abadger1999> How do we tell that scl-X is really being maintained by the X-SIG?
16:22:53 <mattdm> samkottler / geppetto -- we definitely want the people with the expertise to be able to do the work. the WG or whatever would exist to coordinate and empower
16:23:02 <langdon> samkottler: geppetto i don't think that "ruby sig only" is necessarily a good idea, "my cool new app sig" might want ruby that stays stable.. but ruby sig might be all about ruby 2.bleeding.. so i think we would have to be careful
16:23:11 <abadger1999> mattdm: -1  cart before the horse.
16:23:23 <samkottler> right, my point is that the SIG's should be involved in the runtime maintenence
16:23:42 <abadger1999> mattdm: We could say, "This is being revisted and progress on Packaging Guidelines to allow these in is being made"
16:23:47 <samkottler> but of course, "stack" packages can build their own stuff
16:24:33 <geppetto> mattdm: What's the point of that change … a change from "no" to "yes, but you have to adhere to some guidlines that aren't approved and we don't know when they'll be approved" doesn't seem like much of a change, to me.
16:24:44 <tibbs|w> Agreed, I see no point.
16:25:04 <mattdm> okay, but are we actually at the point where it's just about figuring out the guidelines?
16:25:55 <abadger1999> mattdm: I think for the majority of fpc members we agree that fesco gets to decide what to package (SCLs) and FPC decides how to package it.
16:26:15 * RemiFedora nods
16:26:32 <abadger1999> geppetto, Rathann:  I think you were the two that were most wanting fesco to make clear that they wanted scls in, would you agree to that?
16:26:40 <mattdm> okay. so, I think I'm very safe in saying that the Fesco is on board with having SCLs packaged.
16:26:43 <geppetto> abadger1999: But part of that is how/when you can package it … and I didn't see anything from FESCO answering the usecase question.
16:26:48 * abadger1999 sees racor is here too and notes that he thinks racor would not agtree with that.
16:26:52 <abadger1999> #chair racor
16:26:53 <zodbot> Current chairs: Rathann RemiFedora SmootherFrOgZ abadger1999 geppetto racor tibbs|w
16:27:20 <geppetto> mattdm: So FESCO is happy to have anyone package any SCL they feel like?
16:27:28 <abadger1999> geppetto: Well, I think fesco voted to allow all use-cases of SCLs.
16:27:50 <abadger1999> geppetto: and then it's 1) up to us whether there's different ways each use-case should be packaged.
16:28:30 <abadger1999> geppetto: 2) Maybe my fault but in an earlier fesco meeting I had said there would probably be some overlap andI was willing to work on those areas in the FPC and then take it to fesco so they could review and approve if they felt necessary.
16:28:50 <Rathann> abadger1999: I don't remember deferring to FESCo, just saying I don't like the whole idea without specific and solid use cases which can't be done within current FPG
16:29:03 <abadger1999> overlap meaning the how to package and what to package intersecting... I think the criteria that we've been discussing is in that area.
16:29:21 <samkottler> There needs to be some way to track which runtimes are being rebuilt by which groups and who maintains stuff at the very least. Otherwise it's going to be security hysteria.
16:29:22 <mattdm> geppetto within the basic guidelines of what we can package into fedora at all, and trusting that some rational guidelines and process exist, yes
16:30:34 <mattdm> (at least that's my basic interpretation.)
16:31:00 <geppetto> mattdm: part of the current "rational guidelines" is that you can't have multiple versions of things, or bundle things … SCLs at their core break both of those … I'm assuming nobody wants SCLs but you must adhere to the current rational guidelines.
16:31:02 <bkabrda> samkottler: we could probably create some per-scl wiki pages (similar to Changes), that would document the scl owners and purpose/backward compat level of scls?
16:31:30 <geppetto> So part of saying "SCLs can happen" is also saying _why_/_when_ they can happen.
16:31:49 <abadger1999> Rathann: okay.  Would you be willing to consider that position now (it's the traditional relationship of FPC and fesco)?  Or do you want to vote against scl inclusion without that?
16:32:18 <mattdm> geppetto define "bundle" in this context. the SCLs as the exist in bkabrda's homeless project actually have de-bundled RPMs
16:32:27 <abadger1999> err... we don't have a rule about multiple versions of things.
16:32:43 <abadger1999> we have a rule against bundling but this isn't really transgressing it.... anymore than mingw is transgressing it.
16:33:04 <Rathann> abadger1999: sure, but with the caveat that we might end up saying "it can't be done" if we can't come up with something sane
16:33:25 <abadger1999> Rathann: works for me.
16:33:27 <geppetto> abadger1999: Packagers can't just start packaging N versions of whatever they want.
16:33:39 <mattdm> I'm pretty confident that something sane can be come up with
16:33:56 <mattdm> geppetto Okay, I'll bite. If they commit to supporting them, why not?
16:33:57 <samkottler> there is work to be done around SCL namespacing
16:34:06 <samkottler> but I don't think it should be a blocker
16:34:09 <geppetto> abadger1999: And we'll be shipping similar branches of FOO in multiple rpms … which is the spirit of bundling.
16:34:21 <abadger1999> geppetto: I'm pretty sure according to guidelines they can.
16:34:28 <mattdm> samkottler yes, that goes to "this isn't perfect"
16:34:42 <abadger1999> geppetto: if enough of them get made, an scmadmin may step in and say, "why you do this?"
16:34:53 <samkottler> mattdm: yep, just pointing out a specific point of imperfection
16:35:00 <abadger1999> but there's nothing in the guidelines that prevent it yet.
16:35:25 <abadger1999> samkottler: It needs to be a blocker.  guidelines would be insufficient if they didn't address that.
16:35:27 <mattdm> I think, specifically, we _need_ to allow multiple versions of packages in Fedora in some way.
16:35:38 <mattdm> This is precisely the problem we need to address.
16:35:58 <mattdm> This is a differnet problem than bundling (or "vendoring", as the kids today call it)
16:36:02 <samkottler> abadger1999: it's a nice to have, though, not a critical piece of functionality
16:36:44 <mattdm> We also need to figure out a way to deal with that. But SCLs are actually relativiely conservative.
16:36:47 <abadger1999> samkottler: Going forward with potentially conflicting package names being something known to be a problem is pretty bad: http://fedoraproject.org/wiki/Packaging:Conflicts#Conflicting_Package_Names
16:37:15 <samkottler> abadger1999: yeah, that's another reason that namespace definitions by language SIG's are something I support
16:37:20 <abadger1999> anyhow.... I think we're getting off into a meta discussion again.
16:37:31 <samkottler> i.e. should every "stack" be able to use the "ruby193" namespace?
16:37:36 <samkottler> and the answer is clearly no
16:37:38 <samkottler> but then who gets it?
16:37:50 <abadger1999> Since we have bkabrda here today, I'd much prefer if we could talk about some of the "technical details" so that we can move forwards on things.
16:38:13 <tibbs|w> We haven't really prevented multiple versions of things in Fedora, except for a couple of cases where the maintainers really begged us not to do so.
16:38:27 <tibbs|w> Kernel, python 2.4 are all I recall.
16:38:43 <abadger1999> samkottler: What tibbs|w said with the addition that those went to fesco to decide to say no rather than fpc.
16:38:44 <tibbs|w> And "us" might have been FESCo at the time.
16:38:49 <mattdm> abadger1999 Yep. I think I'm done with the other part for now. :)
16:39:56 <abadger1999> We had a couple questions for bkabrda form last meeting.  One he answered in ticket
16:39:57 <langdon> abadger1999: propose that you bring back your "list of 5", ask the voters to approve that as a complete list, address the list of "5" ?
16:40:09 <nirik> I wonder... would it be possible to get a set of _specific_ cases groups are hoping SCL's would help them with? ie, talk to openstack, rails, etc folks and get a list of packages and why they need something to handle those cases? because I think things get bogged down in theory way too much.
16:40:15 <abadger1999> actually only part of that one.  so let me ask both of them here
16:40:41 <geppetto> nirik: Yes, I've asked multiple people to do something like that.
16:40:42 * nirik butts back out, just thought that might help me at least with them.
16:40:49 <tibbs|w> nirik: I would assume that FESCo considered that kind of thing already.
16:40:51 <abadger1999> baptistemm: what packages can't be natively parallel installed and why? (compat packages, python26, etc already exist)
16:40:56 <abadger1999> bkabrda: ^
16:41:31 <nirik> tibbs|w: not to my knowledge.
16:41:50 <bkabrda> abadger1999: well, it's usually not that it'd be undoable, but sometimes it's very painful (Ruby) and it lacks the advantages that I mentioned in the FESCo ticket
16:41:57 <tibbs|w> I mean, didn't someone present a complete use case at some point?
16:42:01 <abadger1999> nirik: yeah, in fpc we've talked about two cases really -- ruby1.9.3 and puppet.
16:42:22 <langdon> nirik: tibbs|w i think an openstack use case has been added to the ticket
16:42:39 <abadger1999> mattdm has mentioned rails3 (since fedora is moving to rails4).
16:42:40 <bkabrda> abadger1999: also, packaging multiple versions of python packages for the same runtime is not very pleasant and forces you to patch project's __init__ file etc.
16:42:52 <tibbs|w> It's just that I assume that there was a whole lot of preparation and discussion before the matter actually got down to us.
16:43:05 <abadger1999> bkabrda: Really?  what _init__.py files are you patching?
16:43:20 <mattdm> Yes. To me, it would be a big success if I could tell people who ask about Fedora that we have an easy way for them to choose a rails stack and stick with it across several fedora releases.
16:43:56 <bkabrda> abadger1999: if you want to use the paralelly installed package, you need to patch the __init__ file of the project that wants to use the paralel-installed version (as in "the second one")
16:43:59 <nirik> tibbs|w: in some kind of ideal parallel dimension... ;)
16:44:19 <abadger1999> bkabrda: I know not of what you speak.
16:44:32 <bkabrda> abadger1999: give me a second to find you a link...
16:44:37 <abadger1999> bkabrda: Cool.   thanks.
16:45:00 <racor> abadger1999: /me is here, but I am semi-absent, because I am currently busy with other jobs in parallel, sorry.
16:45:31 <abadger1999> The comments on scl's advantages that bkabrda speaks of are here: https://fedorahosted.org/fesco/ticket/1175#comment:5
16:45:39 <abadger1999> racor: no problem.  Thanks.
16:45:45 <bkabrda> abadger1999: (couldn't find the reference in setuptools for that, so I'm posting a SO link) http://stackoverflow.com/questions/5265731/python-if-there-are-multiple-egg-versions-of-the-same-package-installed-how-do
16:46:44 <langdon> so.. a question, does the "packaging of an scl" get effected by the "use case"? as in .. isn't it (insert fesco, sig, scl sig, whatever) responsibility to approve the use case for an scl? but that doesn't change how it is packaged, does it?
16:46:47 <samkottler> mattdm: not gonna lie, ruby people just don't care about RPM's
16:47:02 <samkottler> mattdm: they'll just build a ruby and manage it with rbenv or chruby and gem install in production
16:47:09 <samkottler> </harsh reality>
16:47:19 <bkabrda> to get back to my point, openstack is really interested in getting their scl to stabilize their dependencies, because it keeps getting harder for them on ever-changing fedora
16:48:28 <Rathann> langdon: speaking for myself, I'm trying to get a feeling if the SCLs make sense in Fedora at all, that's why I keep asking for the problems that they solve
16:48:35 <apevec> bkabrda, abadger1999 - here's example of patches _init_ in an openstack-keystone http://pkgs.fedoraproject.org/cgit/openstack-keystone.git/tree/openstack-keystone-newdeps.patch?h=el6
16:48:43 <Rathann> last week they were looking like a solution looking for a problem to me
16:48:54 <Rathann> this week I finally see some answers
16:49:00 <langdon> Rathann: ohh.. i totally get that.. but isn't that the fesco conversation? not this one?
16:49:34 <geppetto> bkabrda: That's not how you'd package it in a distro. though.
16:49:44 <abadger1999> bkabrda: ohhhh --- you're talking about something completely different than I am.
16:49:53 <bkabrda> abadger1999: ah, srry :)
16:49:55 <geppetto> bkabrda: Or in SCLs
16:50:26 <abadger1999> bkabrda: you're talking at the individual module level  -- which may not be packagable in scls according to some of the criteria that mmaslano and langdon have proposed.
16:50:42 <geppetto> samkottler: So what's the point in shipping any ruby at all then … might as well just ship "gem" command and give up.
16:50:46 <Rathann> it might well be, but doing something at all must make sense to me if I'm to work out how to do it
16:50:51 <abadger1999> bkabrda: I was thinking there was some problem if you had python2.7 and python3.3 both installed.
16:51:38 <samkottler> geppetto: because we have to build an OS and ship stuff on top of it? and the application stuff we ship needs to be built into RPM's
16:51:41 <samkottler> for lots of reasons
16:51:43 <abadger1999> bkabrda: Re: openstack: is that the things that they depend on or the things that they want others to depend on (inside of openstack)?
16:51:50 <bkabrda> abadger1999: nope :) my point is that these projects are having _very_ hard time managing their dependency stacks, which forces them to package different versions of different packages into different Fedoras. that goes away with SCLs
16:51:58 <mattdm> geppetto I want to explore how we can better do that too. But that's a little further out.
16:52:19 <bkabrda> abadger1999: direct openstack dependency set
16:52:42 <abadger1999> langdon: re: use case and guidelines:  it does affect it.  100% backwards compat is part of a use case and it means different packaging is called for than a minimal backwards compat use case.
16:53:21 <Rathann> bkabrda: the generic/support(application?) division of SCLs does sit well with me, thanks for that idea
16:53:34 <bkabrda> Rathann: YW :)
16:55:22 <langdon> Rathann: abadger1999 just trying to clarify if there is a need to "approve" the use cases or that they are just informing the solution.. will try to avoid talking now so use cases can be discussed :)
16:55:23 <abadger1999> bkabrda: I mean, I want to clarify what "dependency stack" means.  Is it the packages that openstack depends on?  Or the things that depend on the core openstack?
16:55:26 * mattdm has a phone call at 1
16:56:07 <bkabrda> abadger1999: the things that openstack depends on. as in openstack-keystone depends on python-foo
16:56:10 <Rathann> langdon: I think every SCL would need justification why it's better to implement it as SCL than as standard packages
16:57:01 <abadger1999> langdon: I think fesco basically approved the use cases at yesterday's meeting.  at least I hoped we could take that as the result of fesco's vote :-)
16:57:05 <apevec> abadger1999, it is packages that openstack depends on, see https://github.com/openstack/requirements/blob/master/global-requirements.txt
16:57:09 <abadger1999> bkabrda: cool.  thanks.
16:58:04 <langdon> Rathann: +1 definitely should be required as a stmt; abadger1999 +1
16:59:05 <bkabrda> Rathann: +1
17:00:34 * RemiFedora thinks to another use case... when I see the problem with mysql/mariadb... just push mysql as a SCL... trivial, simple... and works.
17:00:43 <RemiFedora> Yes, we know hnow to package multi-version without SCL, but for each new case, there are new problems.
17:00:47 <RemiFedora> SCL are just a "nice" solution, standard solution, and really the simplest one for user and, the same can be use for all/most of projects.
17:01:26 <RemiFedora> And we are still discussing of "why" SCL.... while we should just be discussing on "how to"
17:01:28 <geppetto> RemiFedora: So then every package that wants to talk to mysql will also package itself as an SCL … sounds awesome.
17:01:38 <samkottler> geppetto: not true
17:01:42 <RemiFedora> geppetto, of course no
17:01:55 <abadger1999> bkabrda: so the answer to this question was "we have not yet identified anyhting that can't be parallel packaged using other methods.  But we think that this method has certain advantages: fesco 1175#comment:5"
17:02:04 <RemiFedora> an app which need to talk with mysql... will talk with a socket.
17:02:07 <nirik> then should we just switch everything? all packages are SCLs since they are so much simpler. :)
17:02:39 <bkabrda> abadger1999: well, I'm not sure. I haven't really tried packaging ruby in parallel, so I can't tell whether it's possible or not
17:03:49 <abadger1999> nirik: yeah -- I was trying to think that through (well -- just limited to all compat stuff)  when I was thinking that all scls owuld have to be thin and that was a mess.  But if some scls are thick and some thin it might be different
17:03:58 * Rathann envisions something similar to the bundling exception process with a set of standard questions that need to be answered for each proposed SCL
17:04:19 <abadger1999> bkabrda: There was another question: What makes scls better than environment modules?
17:04:46 <RemiFedora> Rathann, seems a good idea
17:05:13 <abadger1999> RemiFedora: Hmm... But I don't think the socket is one of the problems with the mysql/mariadb setup?
17:05:24 <abadger1999> RemiFedora: Isn't it more about the client libraries?
17:05:26 <bkabrda> abadger1999: for one thing, environment modules allow you just to alter paths (AFAIK). the SCL enable scriptlet let's you do pretty much anything
17:05:54 <abadger1999> RemiFedora: And to use those we'd either need to say "non-scl packages can depend on scl packages" or we'd have to do as geppetto says and package those packages as scls.
17:06:48 <abadger1999> bkabrda: I think nirik knows environment modules well but I was pretty sure it allowed altering what a command is (via alias?) and also setting any env variables.
17:06:53 <abadger1999> nirik: ^
17:07:01 <Rathann> I think: if we allow SCLs then we should allow "normal" packages to depend on them - this will limit what must go into SCL
17:07:38 <bkabrda> abadger1999: another thing is, that SCLs are full solution including the packaging part - including (let me repeat myself :)) the advantages that I mentioned in the fesco ticket
17:07:49 <Rathann> I feel that SCLs should be as minimal as possible
17:07:55 <geppetto> Rathann: Having cross SCL/non-SCL deps. is going to cause problems, IMO.
17:07:59 <nirik> abadger1999: I haven't looked at them in a long time. ;) I think yes, you can specifiy what command runs and env...
17:08:26 <Rathann> geppetto: what kinds of problems do you see there?
17:09:19 <Rathann> how about "non-scl packages can depend only on SCLs with compatibility guarantees"?
17:09:29 <RemiFedora> probably the same than with other multi-version solution.
17:09:30 <Rathann> but that might be too limiting
17:09:42 <Rathann> ah
17:10:24 <orionp> abadger1999 bkabrda - environment modules can set/unset any environment variable and set/unset aliases
17:10:42 <geppetto> Rathann: 1) non-SCL is a single namespace of depsolving, SCLs are each their own namespace. Those are just vastly different things. 2) packages are meant to be small units, have provides etc., SCLs are meant to be larger groups that just have a root "scl-foo" provide.
17:10:48 <RemiFedora> I means, if you depend of some package (scl or not scl), it must exist and provides the ABI you're expecting, else you have to rebuild. Nothing new here
17:10:50 <geppetto> Rathann: Those are the obvious two.
17:11:18 <Rathann> right
17:11:39 <Rathann> and also you have to set up the environment before your binaries can just work
17:11:39 <abadger1999> bkabrda: How are the autodeps handled? Are they generated into their own namespace?
17:12:01 <Rathann> so yes, allowing non-scl packages to depend on scls doesn't make sense
17:12:02 <abadger1999> like scl(libfoo.so.1(x86_64))  instead of   libfoo.so.1(x86_64) ?
17:12:31 <bkabrda> abadger1999: not yet. that's a problem that's been reported and scl-utils upstream is working on that AFAIK
17:13:13 <abadger1999> bkabrda: where are the errors?  Does it not create auto provides?  Does it not create the autorequires?
17:13:41 <abadger1999> Does it create autorequires that are for the "mainstream rpm" instead of the scl rpm?
17:14:16 <bkabrda> abadger1999: it creates the auto provides in the same way as for system libraries. so the collection library can have the same "libfoo.so.1" provide as the system library
17:15:55 <bkabrda> abadger1999: and then when you try to install a system package that requires that and have the collection installed, the system library isn't installed because the require is already satisfied by the scl li
17:15:59 <bkabrda> *lib
17:16:21 <Rathann> that's a blocker then SCLs shouldn't replace system libraries in this way
17:16:53 <abadger1999> ah.  yeah, it's a blocker for being in fedora but I don't think it blocks work on the guidelines.
17:17:10 <RemiFedora> this is a problem which can be solved by filtering... (temprarily, waiting for a more simple solution)
17:17:31 <bkabrda> ok. I'll try to push the scl-utils upstream to fix this while we're working on the guidelines
17:17:41 <abadger1999> bkabrda: note -- I think when you namespace those you should think about namespacing them with the vendor rather than simply something like "scl".
17:17:45 <RemiFedora> and exactly what need to be written in Guidelines : ex : a SCL must not provides something provided in the system...
17:18:05 <bkabrda> abadger1999: yep. name of the scl might be even better
17:18:25 <abadger1999> bkabrda: probably need to include vendor in the scl name too.
17:19:26 <abadger1999> RemiFedora: Well -- filtering only solves half of the problem right?  It removes the autodeps.  but it doesn't create usable deps.  It means that you have to specify all deps manually.
17:19:37 <abadger1999> (in addition to filtering out all of the autodeps)
17:20:04 <RemiFedora> I mean filetering to modify the autodep (adding the scl prefix)
17:20:58 <RemiFedora> like the pkgconfig example in the draft
17:21:27 <abadger1999> geppetto: So -- if you anticipate problems with non-scl packages Require'ing: SCL packages, that means that BuildRequires of an SCL package would also run into the same issues?
17:21:41 <geppetto> abadger1999: Yeh, same problem.
17:22:03 <geppetto> abadger1999: why?
17:22:26 <abadger1999> nirik: ^ That might be an early answer to the EPEL guy who wanted the devtoolset newer gcc.
17:23:24 <abadger1999> geppetto: do you think we can come up with an example of breakage or would it take a lot of work to create the interaction of packages that would show it?
17:23:46 * abadger1999 can see the conceptual mismatches but isn't sure he sees how that turns into actualy problems.
17:24:55 <bkabrda> abadger1999: the example is quite simple
17:25:06 <bkabrda> you have system foo that provides libfoo.so.1
17:25:22 <geppetto> abadger1999: I think it'd be hard to show "this is a probablem that will happen" … as the problems are more like "when you do this you'll need to understand these 666 non-obvious problems, and if you hit one it might not show up as a problem instantly"
17:25:27 <bkabrda> you package foo into scl, but due to the bug, it also provides libfoo.so.1
17:25:47 <bkabrda> you install scl and you don't have system "foo" package installed
17:25:55 <abadger1999> bkabrda: right -- I think geppetto is talking about when that bug is fixed, we still don't want non-scl packages to dep on scl packages.
17:26:19 <bkabrda> abadger1999: ah sorry... just ignore my last four lines ;)
17:26:23 <abadger1999> no problem :-)
17:26:50 <bkabrda> well actually we might want to do that in cases of what I called the "support" scls in the fesco ticket
17:27:35 <geppetto> bkabrda: Those are like different version of a language stack, right?
17:27:36 <bkabrda> like - you have an scl that provides the dependencies for openstack, but you want to keep openstack as a system package
17:28:02 <bkabrda> geppetto: more like stack of dependencies for certain project
17:28:15 <Rathann> bkabrda: openstack would have to go into the scl
17:28:24 <geppetto> bkabrda: So why is that an SCL, and why is openstack not an SCL?
17:28:36 <Rathann> makes things easier to use
17:28:44 <Rathann> and maintain
17:29:15 <bkabrda> well, because you want users to just install "openstack" and run it as "openstack". the fact that it's deps are in scl are implementation detail that the user shouldn't have to care about
17:30:09 <bkabrda> but then again, this would need to be allowed on per-scl basis with a very clear reasoning why it is done this way, imo
17:32:24 <Rathann> bkabrda: but openstack package would have to be tailored to set-up its scl environment anyway
17:32:34 <bkabrda> Rathann: yes
17:34:05 <abadger1999> So I guess we really should figure out at least one thing that does actually break before making a decision on whether to ban this altogether.
17:34:29 <abadger1999> Since it sounds like a useful use case.
17:35:05 <abadger1999> geppetto: would you be willing to look for something?
17:35:06 <Rathann> indeed
17:36:38 <abadger1999> bkabrda: Something else that I was wondering: SCLs enable parallel installation without filesystem conflicts.  but what about port and socket conflicts?  Like two mysql database servers for instance?
17:37:19 <Rathann> if the "provides" of any SCL don't overlap with either the standard packages or any other SCL then I think there will be no issue since any dependency on SCL specified by a non-scl package will be unambiguously resolved
17:37:21 <RemiFedora> abadger1999, you can only run 1 service or edit config to use differetnet port
17:37:51 <bkabrda> abadger1999: it is best if this is addressed during packaging - e.g. packaging SCL postgress to listen on a different port by default - and of course documenting it
17:37:59 * abadger1999 suddenly wonders what systemd socket activation does when two services provide the same socket.
17:38:01 <Rathann> abadger1999: sendmail vs postfix vs exim
17:38:14 <geppetto> abadger1999: I'm not really sure what you mean … it's kind of obvious that if a pkg "foo" depends on scl-blah123, then it'll need to be intimately aware of that SCL to the point that it's basically part of that SCL namespace.
17:38:36 <Rathann> you can have the installed in parallel already and they use alternatives (well sendmail and postfix do for sure)
17:38:46 <geppetto> abadger1999: If it's just a naming thing "want to be able to do: yum install openstack" even if the scl is called "scl-openstack123" or whatever … then meh.
17:38:47 <abadger1999> geppetto: okay -- so then -- it would be okay for non-scl packages to depend on scl packages?
17:38:53 <abadger1999> k
17:38:57 <Rathann> but you can't run them in parallel without configuration
17:39:04 <abadger1999> Igepi think that covers the use case.
17:39:12 <geppetto> abadger1999: I guess carve out exceptions for metapackage like things? … or something else?
17:40:30 <geppetto> Having a special part of packaging where you choose from the scls, seems better than metapackages, but meh.
17:41:03 <Rathann> geppetto: not sure I'm following
17:41:17 <geppetto> Rathann: As in "yum scl-install openstack"
17:41:34 <Rathann> ugh, we need a special yum command?
17:42:34 <Rathann> hm one more thing - will the SCLs live in a separate repo or in regular repos?
17:42:34 <geppetto> We don't need it … but if the alternative is to have metapackages in the non-SCL namespace just to give better names to things in the scl namespace … using a different interface than just install seems better.
17:42:41 <abadger1999> bkabrda, apevec (I assunme you're working on openstack): thinking about the openstack example more.... the more I think about it the more it sounds like bundling to me.  One of the reasons not to bundle is that you have more parties potentially interested in a package that exists by itself than you do for a package that's tied to a particular application that uses it.  That particular reason would still apply here.
17:42:52 <Rathann> separate repo would limit the metadata overhead for people who don't use SCLs
17:43:09 <Rathann> but then you can't have regular packages in fedora depend on SCLs in separate repo
17:43:29 <abadger1999> bkabrda, apevec: Is there something that addresses that?
17:44:02 <geppetto> Rathann: Separate repo. means it's not really Fedora IMO … and surely we'd want to use SCLs if they solve problems, and users like problems solved.
17:44:24 <Rathann> right
17:44:27 <abadger1999> Rathann: some owuld like in the same repo.  others would live in a separate repo -- its the fedora commons vs fedora outer rings proposal.
17:44:36 <abadger1999> we're mostly concerned with feodra commons here.
17:44:58 <abadger1999> but we can say "X is not allowed in fedora commons but is allowed in the outer rings when they come into being"
17:45:00 <Rathann> that makes me think even more strongly in favour of making the SCLs as minimal as possible
17:45:02 <geppetto> I can see having a separate repos. because of different update policies, but I dont see why SCL/non-SCL would want/require separate repos.
17:45:15 <bkabrda> abadger1999: I don't see it as bundling in the same way I don't see keeping two versions of the same package around in the system
17:46:15 <abadger1999> bkabrda: the thing is -- if I'm packaging foo that depends on a particular version of bar.  is it useful for me that unrelated scl baz has that version of bar?
17:47:09 <bkabrda> abadger1999: well, you can always depend on that unrelated scl, or ask the maintainer of it to create a common scl that you're both going to depend on, i think
17:47:19 <abadger1999> bkabrda: if I have to create my own version of the bar package because I can't make use of scl baz's version of bar then that rationale for non-bundling applies.
17:47:41 <abadger1999> bkabrda: and hten wait for mattdm to file a bug that the dependencies need to be broken up? ;-)
17:48:37 <bkabrda> abadger1999: I'm not answering that question ;)
17:49:03 <abadger1999> hah!
17:49:17 <Rathann> so
17:49:36 <abadger1999> bkabrda: Could you describe how the scl packages get stored in git and built in koji?
17:50:07 <Rathann> what does everyone think about the requirement of unique provides generated for each SCL (by means of a prefix probably)?
17:50:13 <bkabrda> abadger1999: in git, it imo makes sense to store them in separate branches, e.g. <scl-name>-fXX
17:50:13 <abadger1999> bkabrda: and if you know, what would need to chnage so that they could be put into the main Fedora repo instead of side repos.
17:50:58 <bkabrda> for building in koji, you need to add scl-utils-build and <scl-name>-build into minimal buildroot and that's it... so they need their separate buildroots
17:51:01 <Rathann> bkabrda: why separate branches? why can't they be treated like normal packages in git?
17:51:34 <bkabrda> abadger1999: not totally sure about repos. I'd say that nothing needs to be changed, but I'd rather ask someone from rel-engs about this one
17:51:39 <abadger1999> bkabrda: dgilmore asked the other day if scl-utils-build needs to be in the minimal buildroot or if it can be a BuildRequire.
17:52:01 <bkabrda> Rathann: I meant branches in dist-git
17:52:11 <RemiFedora> abadger1999, afaik  <sclname>-build need to be in the buildroot
17:52:29 <abadger1999> bkabrda: Mmm also -- From what you just said, I take it that if scl-utils-build ended up in a "mainstream package" build for some reason, it would cause havoc?
17:52:32 <bkabrda> abadger1999: you need scl-utils-build in buildroot to build metapackage
17:53:21 <bkabrda> abadger1999: what do you mean by "mainstream package build"? like what would happen if we put them in _every_ buildroot?
17:53:28 <abadger1999> bkabrda: yeah.
17:54:22 <abadger1999> If they ended up in the regular f20 build of the Foo package and the Foo package had conditionalized scl macros, then I'm guessing that those macros get expanded and we don't get the package that we intended?
17:54:23 <bkabrda> abadger1999: hmm. I'd say nothing, but I'll need some time to think about possible consequences of this
17:54:46 <abadger1999> oh okay... well if nothing happens, then that's even better :-)
17:54:48 <bkabrda> abadger1999: nope, since if there is no definition of "%scl", scl-utils do nothing
17:54:55 <RemiFedora> bkabrda, I think it's not scl-utils-build , but <sclname>-build this is requires and can cause issue
17:55:26 <abadger1999> oh... and sclname-build also has to be in the buildroot?
17:55:30 <bkabrda> RemiFedora: yeah, the problem would be if you had an %{scl}-build package there. scl-utils-build on their own should be harmless
17:55:34 <RemiFedora> abadger1999, yes
17:55:35 <abadger1999> (it can't simply be a BuildRequires)
17:55:50 <RemiFedora> exactly, %scl need to be defined "before" .src.rpm stuff
17:55:51 <Rathann> bkabrda: I still don't get what you want to do differently with the branches
17:56:25 <abadger1999> bkabrda: about Rathann's question of branches -- at the last meeting we discussed how mingw does something similar and they use separate packages rather than separate branches.
17:56:29 <bkabrda> abadger1999: not totally sure about this. I worked with a koji instance that had some limitations set up that forced us to put sclname-build in buildroot and not as a requirement, but fedora's koji may be set up differently. I'd need to ask relengs
17:56:33 <abadger1999> So that's where the question is coming from.
17:56:43 <abadger1999> k
17:57:05 <Rathann> RemiFedora: why not follow the mingw case? AFAIR no mingw package is in the default buildroot
17:57:28 <bkabrda> Rathann: currently, you have master, f20, f19, ... in dist-git repo. so collections would just add sclname-FXX branch and live there. am I saying it clearly now?
17:57:32 * Rathann checks to be sure
17:57:53 <RemiFedora> Rathann, I think if you define %scl in each spec, it will work
17:58:01 <abadger1999> bkabrda: rathann's asking what the advantage and disadvantage is for a branch vs a separate package.
17:58:13 <Rathann> bkabrda: so you want to have scl branches inside each package's git repo?
17:58:17 <abadger1999> One of hte advantages is that we don't have to conditionalize everything.
17:58:24 <bkabrda> Rathann: right
17:58:29 <Rathann> ewwww
17:58:32 <RemiFedora> review !
17:58:45 <RemiFedora> new package = new review while new branch = scn request ;)
17:59:01 * abadger1999 notes that certain fesco members also had eww moments about that -- they thought that there would be a new package for the scl packages.
17:59:05 <Rathann> what if the maintainer of the package doesn't want any SCL branches?
17:59:31 <RemiFedora> Rathann, I think it's the packager choice, exactly like for EPEL branch
17:59:32 <bkabrda> Rathann: I don't see how the branches would get in his way
17:59:47 <Rathann> hm
18:00:23 * rbergeron wonders if board meeting is bumping into you guys
18:00:27 <bkabrda> and imo it would make merging patches easier, if you had branches in the same repo
18:00:36 <abadger1999> rbergeron: We can move -- we're over time.
18:00:37 <Rathann> I thought each SCL would be reviewed as a single entity
18:00:38 <RemiFedora> abadger1999, there is a new package => the main scl package (metapackage)
18:00:52 <abadger1999> FPC members -- would it be okay with you all if we move to #scl ?
18:00:54 <Rathann> and would be a separate package
18:01:05 * abadger1999 notes there's no zodbot there.
18:01:22 <rbergeron> abadger1999: except... zodbot
18:01:23 <abadger1999> Maybe #fedora-meeting-2
18:01:37 <rbergeron> oh, you mean where you'd move to
18:01:39 <abadger1999> FPC ^
18:01:45 <abadger1999> rbergeron: yeah, where we'll move.
18:02:27 * abadger1999 here's no objections.... FPC members probably just want to go home ;-)
18:02:33 <abadger1999> #endmeeting