16:02:30 #startmeeting fpc 16:02:30 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 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:02:36 #topic Roll Call 16:02:39 * geppetto is here 16:02:49 #chair abadger1999 geppetto 16:02:49 Current chairs: abadger1999 geppetto 16:03:04 Cheers. 16:03:36 ping spot, RemiFedora, SmootherFrOgZ FPC meeting 16:03:52 * RemiFedora here 16:04:04 #chair RemiFedora 16:04:04 Current chairs: RemiFedora abadger1999 geppetto 16:04:06 * samkottler is here 16:04:13 #chair tibbs|w 16:04:13 Current chairs: RemiFedora abadger1999 geppetto tibbs|w 16:04:37 Not enough for quorum yet... racor said he might not be able to make it to this week's meeting. 16:04:57 We weren't going to get to a vote on scls anyow so it might not matter. 16:05:13 bkabrda is here this week to answer technical questions. 16:05:27 Would be super nice if we could actually get to something else on the agenda as well. 16:05:30 yep 16:06:05 tibbs|w vote yes and let's move on :) 16:06:15 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 mattdm: amen 16:06:48 #chair Rathann 16:06:48 Current chairs: Rathann RemiFedora abadger1999 geppetto tibbs|w 16:08:05 #topic SCLs https://fedorahosted.org/fpc/ticket/339 16:08:41 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 https://fedorahosted.org/fesco/ticket/1175 <= fesco ticket for our questoins last week 16:09:06 fesco basically said, 16:09:10 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 backwards compat guarantees can be decided per-scl. 16:09:30 #chair SmootherFrOgZ 16:09:30 Current chairs: Rathann RemiFedora SmootherFrOgZ abadger1999 geppetto tibbs|w 16:10:12 and can range fronm 0 backwards compat guarantee to 100% backwards compat. The requirement is for the scl to document that. 16:10:33 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 1) thick or thin (I'm now thinking both depending on the extent of backwards compat guarantees). 16:13:17 2) Criteria for approing an scl 16:13:33 3) naming -- what prefix? what form for the version? 16:13:33 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 4) Where do things get installed? 16:14:33 abadger1999 I think I would categorize all of those as "guidelines detail work". 16:14:49 geppetto do you mean 'where in the filesystem' or 'from what repository'? 16:14:49 And, yeh, abadger1999's #2 is the main other thing for me … how do SCLs get into the distro. 16:15:18 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 mattdm: Presumably if we approve them they'll be in the fedora/updates repos. … otherwise they aren't Fedora. 16:15:50 geppetto so then it's a matter of /opt vs. /usr/lib/scl vs. whatever? 16:15:57 mattdm: isn't that what you asked me to list? The things that are technical decisions we need to make? 16:16:01 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 mattdm: Right. 16:16:19 +1 for a SCL SIG 16:16:31 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 -1 to SCL SIG. and -1 to FESCo. 16:16:44 (not for SCL approval, but for documentation, help, ...) 16:16:45 abadger1999 I'm making a distinction between a general "SCLs are okay for some cases" and the specific rules for implementation 16:17:03 abadger1999: What would you prefer to SCL SIG? 16:17:17 But we could talk about the Environments and Stack WG. 16:17:23 Environments and Stacks Working Group as part of Fedora.next proposal 16:17:33 right abadger1999 :) 16:17:36 Yeah. 16:18:21 RemiFedora: ah, yeah, for documentation and help that would be fine. 16:18:36 abadger1999: mattdm: you this WG would approve SCLs? 16:18:41 *you mean 16:18:55 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 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 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 abadger1999: ok, that sounds good 16:20:11 even though i am all for making sure that the details actually work 16:20:13 mattdm: Well, what's should I redo the electrical in my house? 16:20:33 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 abadger1999 one sec 16:20:58 I think it's actually important for language SIG's to maintain their SCL's 16:21:15 we're reconstructing the whole house with Fedora.next, so why not redo the electrical while at it ;) 16:21:34 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 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 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 samkottler: SIGs are pretty loose to be able to make that a requirement. 16:22:53 How do we tell that scl-X is really being maintained by the X-SIG? 16:22:53 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 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 mattdm: -1 cart before the horse. 16:23:23 right, my point is that the SIG's should be involved in the runtime maintenence 16:23:42 mattdm: We could say, "This is being revisted and progress on Packaging Guidelines to allow these in is being made" 16:23:47 but of course, "stack" packages can build their own stuff 16:24:33 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 Agreed, I see no point. 16:25:04 okay, but are we actually at the point where it's just about figuring out the guidelines? 16:25:55 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 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 okay. so, I think I'm very safe in saying that the Fesco is on board with having SCLs packaged. 16:26:43 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 #chair racor 16:26:53 Current chairs: Rathann RemiFedora SmootherFrOgZ abadger1999 geppetto racor tibbs|w 16:27:20 mattdm: So FESCO is happy to have anyone package any SCL they feel like? 16:27:28 geppetto: Well, I think fesco voted to allow all use-cases of SCLs. 16:27:50 geppetto: and then it's 1) up to us whether there's different ways each use-case should be packaged. 16:28:30 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 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 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 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 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 (at least that's my basic interpretation.) 16:31:00 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 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 So part of saying "SCLs can happen" is also saying _why_/_when_ they can happen. 16:31:49 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 geppetto define "bundle" in this context. the SCLs as the exist in bkabrda's homeless project actually have de-bundled RPMs 16:32:27 err... we don't have a rule about multiple versions of things. 16:32:43 we have a rule against bundling but this isn't really transgressing it.... anymore than mingw is transgressing it. 16:33:04 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 Rathann: works for me. 16:33:27 abadger1999: Packagers can't just start packaging N versions of whatever they want. 16:33:39 I'm pretty confident that something sane can be come up with 16:33:56 geppetto Okay, I'll bite. If they commit to supporting them, why not? 16:33:57 there is work to be done around SCL namespacing 16:34:06 but I don't think it should be a blocker 16:34:09 abadger1999: And we'll be shipping similar branches of FOO in multiple rpms … which is the spirit of bundling. 16:34:21 geppetto: I'm pretty sure according to guidelines they can. 16:34:28 samkottler yes, that goes to "this isn't perfect" 16:34:42 geppetto: if enough of them get made, an scmadmin may step in and say, "why you do this?" 16:34:53 mattdm: yep, just pointing out a specific point of imperfection 16:35:00 but there's nothing in the guidelines that prevent it yet. 16:35:25 samkottler: It needs to be a blocker. guidelines would be insufficient if they didn't address that. 16:35:27 I think, specifically, we _need_ to allow multiple versions of packages in Fedora in some way. 16:35:38 This is precisely the problem we need to address. 16:35:58 This is a differnet problem than bundling (or "vendoring", as the kids today call it) 16:36:02 abadger1999: it's a nice to have, though, not a critical piece of functionality 16:36:44 We also need to figure out a way to deal with that. But SCLs are actually relativiely conservative. 16:36:47 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 abadger1999: yeah, that's another reason that namespace definitions by language SIG's are something I support 16:37:20 anyhow.... I think we're getting off into a meta discussion again. 16:37:31 i.e. should every "stack" be able to use the "ruby193" namespace? 16:37:36 and the answer is clearly no 16:37:38 but then who gets it? 16:37:50 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 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 Kernel, python 2.4 are all I recall. 16:38:43 samkottler: What tibbs|w said with the addition that those went to fesco to decide to say no rather than fpc. 16:38:44 And "us" might have been FESCo at the time. 16:38:49 abadger1999 Yep. I think I'm done with the other part for now. :) 16:39:56 We had a couple questions for bkabrda form last meeting. One he answered in ticket 16:39:57 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 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 actually only part of that one. so let me ask both of them here 16:40:41 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 nirik: I would assume that FESCo considered that kind of thing already. 16:40:51 baptistemm: what packages can't be natively parallel installed and why? (compat packages, python26, etc already exist) 16:40:56 bkabrda: ^ 16:41:31 tibbs|w: not to my knowledge. 16:41:50 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 I mean, didn't someone present a complete use case at some point? 16:42:01 nirik: yeah, in fpc we've talked about two cases really -- ruby1.9.3 and puppet. 16:42:22 nirik: tibbs|w i think an openstack use case has been added to the ticket 16:42:39 mattdm has mentioned rails3 (since fedora is moving to rails4). 16:42:40 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 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 bkabrda: Really? what _init__.py files are you patching? 16:43:20 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 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 tibbs|w: in some kind of ideal parallel dimension... ;) 16:44:19 bkabrda: I know not of what you speak. 16:44:32 abadger1999: give me a second to find you a link... 16:44:37 bkabrda: Cool. thanks. 16:45:00 abadger1999: /me is here, but I am semi-absent, because I am currently busy with other jobs in parallel, sorry. 16:45:31 The comments on scl's advantages that bkabrda speaks of are here: https://fedorahosted.org/fesco/ticket/1175#comment:5 16:45:39 racor: no problem. Thanks. 16:45:45 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 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 mattdm: not gonna lie, ruby people just don't care about RPM's 16:47:02 mattdm: they'll just build a ruby and manage it with rbenv or chruby and gem install in production 16:47:09 16:47:19 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 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 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 last week they were looking like a solution looking for a problem to me 16:48:54 this week I finally see some answers 16:49:00 Rathann: ohh.. i totally get that.. but isn't that the fesco conversation? not this one? 16:49:34 bkabrda: That's not how you'd package it in a distro. though. 16:49:44 bkabrda: ohhhh --- you're talking about something completely different than I am. 16:49:53 abadger1999: ah, srry :) 16:49:55 bkabrda: Or in SCLs 16:50:26 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 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 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 bkabrda: I was thinking there was some problem if you had python2.7 and python3.3 both installed. 16:51:38 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 for lots of reasons 16:51:43 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 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 geppetto I want to explore how we can better do that too. But that's a little further out. 16:52:19 abadger1999: direct openstack dependency set 16:52:42 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 bkabrda: the generic/support(application?) division of SCLs does sit well with me, thanks for that idea 16:53:34 Rathann: YW :) 16:55:22 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 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 abadger1999: the things that openstack depends on. as in openstack-keystone depends on python-foo 16:56:10 langdon: I think every SCL would need justification why it's better to implement it as SCL than as standard packages 16:57:01 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 abadger1999, it is packages that openstack depends on, see https://github.com/openstack/requirements/blob/master/global-requirements.txt 16:57:09 bkabrda: cool. thanks. 16:58:04 Rathann: +1 definitely should be required as a stmt; abadger1999 +1 16:59:05 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 Yes, we know hnow to package multi-version without SCL, but for each new case, there are new problems. 17:00:47 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 And we are still discussing of "why" SCL.... while we should just be discussing on "how to" 17:01:28 RemiFedora: So then every package that wants to talk to mysql will also package itself as an SCL … sounds awesome. 17:01:38 geppetto: not true 17:01:42 geppetto, of course no 17:01:55 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 an app which need to talk with mysql... will talk with a socket. 17:02:07 then should we just switch everything? all packages are SCLs since they are so much simpler. :) 17:02:39 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 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 bkabrda: There was another question: What makes scls better than environment modules? 17:04:46 Rathann, seems a good idea 17:05:13 RemiFedora: Hmm... But I don't think the socket is one of the problems with the mysql/mariadb setup? 17:05:24 RemiFedora: Isn't it more about the client libraries? 17:05:26 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 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 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 nirik: ^ 17:07:01 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 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 I feel that SCLs should be as minimal as possible 17:07:55 Rathann: Having cross SCL/non-SCL deps. is going to cause problems, IMO. 17:07:59 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 geppetto: what kinds of problems do you see there? 17:09:19 how about "non-scl packages can depend only on SCLs with compatibility guarantees"? 17:09:29 probably the same than with other multi-version solution. 17:09:30 but that might be too limiting 17:09:42 ah 17:10:24 abadger1999 bkabrda - environment modules can set/unset any environment variable and set/unset aliases 17:10:42 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 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 Rathann: Those are the obvious two. 17:11:18 right 17:11:39 and also you have to set up the environment before your binaries can just work 17:11:39 bkabrda: How are the autodeps handled? Are they generated into their own namespace? 17:12:01 so yes, allowing non-scl packages to depend on scls doesn't make sense 17:12:02 like scl(libfoo.so.1(x86_64)) instead of libfoo.so.1(x86_64) ? 17:12:31 abadger1999: not yet. that's a problem that's been reported and scl-utils upstream is working on that AFAIK 17:13:13 bkabrda: where are the errors? Does it not create auto provides? Does it not create the autorequires? 17:13:41 Does it create autorequires that are for the "mainstream rpm" instead of the scl rpm? 17:14:16 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 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 *lib 17:16:21 that's a blocker then SCLs shouldn't replace system libraries in this way 17:16:53 ah. yeah, it's a blocker for being in fedora but I don't think it blocks work on the guidelines. 17:17:10 this is a problem which can be solved by filtering... (temprarily, waiting for a more simple solution) 17:17:31 ok. I'll try to push the scl-utils upstream to fix this while we're working on the guidelines 17:17:41 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 and exactly what need to be written in Guidelines : ex : a SCL must not provides something provided in the system... 17:18:05 abadger1999: yep. name of the scl might be even better 17:18:25 bkabrda: probably need to include vendor in the scl name too. 17:19:26 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 (in addition to filtering out all of the autodeps) 17:20:04 I mean filetering to modify the autodep (adding the scl prefix) 17:20:58 like the pkgconfig example in the draft 17:21:27 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 abadger1999: Yeh, same problem. 17:22:03 abadger1999: why? 17:22:26 nirik: ^ That might be an early answer to the EPEL guy who wanted the devtoolset newer gcc. 17:23:24 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 abadger1999: the example is quite simple 17:25:06 you have system foo that provides libfoo.so.1 17:25:22 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 you package foo into scl, but due to the bug, it also provides libfoo.so.1 17:25:47 you install scl and you don't have system "foo" package installed 17:25:55 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 abadger1999: ah sorry... just ignore my last four lines ;) 17:26:23 no problem :-) 17:26:50 well actually we might want to do that in cases of what I called the "support" scls in the fesco ticket 17:27:35 bkabrda: Those are like different version of a language stack, right? 17:27:36 like - you have an scl that provides the dependencies for openstack, but you want to keep openstack as a system package 17:28:02 geppetto: more like stack of dependencies for certain project 17:28:15 bkabrda: openstack would have to go into the scl 17:28:24 bkabrda: So why is that an SCL, and why is openstack not an SCL? 17:28:36 makes things easier to use 17:28:44 and maintain 17:29:15 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 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 bkabrda: but openstack package would have to be tailored to set-up its scl environment anyway 17:32:34 Rathann: yes 17:34:05 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 Since it sounds like a useful use case. 17:35:05 geppetto: would you be willing to look for something? 17:35:06 indeed 17:36:38 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 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 abadger1999, you can only run 1 service or edit config to use differetnet port 17:37:51 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 abadger1999: sendmail vs postfix vs exim 17:38:14 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 you can have the installed in parallel already and they use alternatives (well sendmail and postfix do for sure) 17:38:46 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 geppetto: okay -- so then -- it would be okay for non-scl packages to depend on scl packages? 17:38:53 k 17:38:57 but you can't run them in parallel without configuration 17:39:04 Igepi think that covers the use case. 17:39:12 abadger1999: I guess carve out exceptions for metapackage like things? … or something else? 17:40:30 Having a special part of packaging where you choose from the scls, seems better than metapackages, but meh. 17:41:03 geppetto: not sure I'm following 17:41:17 Rathann: As in "yum scl-install openstack" 17:41:34 ugh, we need a special yum command? 17:42:34 hm one more thing - will the SCLs live in a separate repo or in regular repos? 17:42:34 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 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 separate repo would limit the metadata overhead for people who don't use SCLs 17:43:09 but then you can't have regular packages in fedora depend on SCLs in separate repo 17:43:29 bkabrda, apevec: Is there something that addresses that? 17:44:02 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 right 17:44:27 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 we're mostly concerned with feodra commons here. 17:44:58 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 that makes me think even more strongly in favour of making the SCLs as minimal as possible 17:45:02 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 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 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 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 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 bkabrda: and hten wait for mattdm to file a bug that the dependencies need to be broken up? ;-) 17:48:37 abadger1999: I'm not answering that question ;) 17:49:03 hah! 17:49:17 so 17:49:36 bkabrda: Could you describe how the scl packages get stored in git and built in koji? 17:50:07 what does everyone think about the requirement of unique provides generated for each SCL (by means of a prefix probably)? 17:50:13 abadger1999: in git, it imo makes sense to store them in separate branches, e.g. -fXX 17:50:13 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 for building in koji, you need to add scl-utils-build and -build into minimal buildroot and that's it... so they need their separate buildroots 17:51:01 bkabrda: why separate branches? why can't they be treated like normal packages in git? 17:51:34 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 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 Rathann: I meant branches in dist-git 17:52:11 abadger1999, afaik -build need to be in the buildroot 17:52:29 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 abadger1999: you need scl-utils-build in buildroot to build metapackage 17:53:21 abadger1999: what do you mean by "mainstream package build"? like what would happen if we put them in _every_ buildroot? 17:53:28 bkabrda: yeah. 17:54:22 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 abadger1999: hmm. I'd say nothing, but I'll need some time to think about possible consequences of this 17:54:46 oh okay... well if nothing happens, then that's even better :-) 17:54:48 abadger1999: nope, since if there is no definition of "%scl", scl-utils do nothing 17:54:55 bkabrda, I think it's not scl-utils-build , but -build this is requires and can cause issue 17:55:26 oh... and sclname-build also has to be in the buildroot? 17:55:30 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 abadger1999, yes 17:55:35 (it can't simply be a BuildRequires) 17:55:50 exactly, %scl need to be defined "before" .src.rpm stuff 17:55:51 bkabrda: I still don't get what you want to do differently with the branches 17:56:25 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 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 So that's where the question is coming from. 17:56:43 k 17:57:05 RemiFedora: why not follow the mingw case? AFAIR no mingw package is in the default buildroot 17:57:28 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 Rathann, I think if you define %scl in each spec, it will work 17:58:01 bkabrda: rathann's asking what the advantage and disadvantage is for a branch vs a separate package. 17:58:13 bkabrda: so you want to have scl branches inside each package's git repo? 17:58:17 One of hte advantages is that we don't have to conditionalize everything. 17:58:24 Rathann: right 17:58:29 ewwww 17:58:32 review ! 17:58:45 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 what if the maintainer of the package doesn't want any SCL branches? 17:59:31 Rathann, I think it's the packager choice, exactly like for EPEL branch 17:59:32 Rathann: I don't see how the branches would get in his way 17:59:47 hm 18:00:23 * rbergeron wonders if board meeting is bumping into you guys 18:00:27 and imo it would make merging patches easier, if you had branches in the same repo 18:00:36 rbergeron: We can move -- we're over time. 18:00:37 I thought each SCL would be reviewed as a single entity 18:00:38 abadger1999, there is a new package => the main scl package (metapackage) 18:00:52 FPC members -- would it be okay with you all if we move to #scl ? 18:00:54 and would be a separate package 18:01:05 * abadger1999 notes there's no zodbot there. 18:01:22 abadger1999: except... zodbot 18:01:23 Maybe #fedora-meeting-2 18:01:37 oh, you mean where you'd move to 18:01:39 FPC ^ 18:01:45 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 #endmeeting