16:02:36 <abadger1999> #startmeeting fpc
16:02:36 <zodbot> Meeting started Thu Sep 12 16:02:36 2013 UTC.  The chair is abadger1999. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:02:36 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:02:41 <abadger1999> #topic Roll Call
16:02:43 * geppetto is here
16:02:54 <abadger1999> #chair geppetto tibbs|w
16:02:54 <zodbot> Current chairs: abadger1999 geppetto tibbs|w
16:03:14 <abadger1999> RemiFedora, spot, limburgher, SmootherFrOgZ: You guys around for FPC meeting?
16:03:25 <RemiFedora> yes
16:03:32 <abadger1999> #chair RemiFedora
16:03:32 <zodbot> Current chairs: RemiFedora abadger1999 geppetto tibbs|w
16:03:51 * limburgher here
16:03:57 <abadger1999> #chair limburgher
16:03:57 <zodbot> Current chairs: RemiFedora abadger1999 geppetto limburgher tibbs|w
16:04:07 <abadger1999> That's quorum but just barely.
16:04:10 * handsome_pirate waves
16:04:14 <abadger1999> langdon: Are you here?
16:05:28 * SmootherFrOgZ is around
16:06:07 <abadger1999> #chair SmootherFrOgZ
16:06:07 <zodbot> Current chairs: RemiFedora SmootherFrOgZ abadger1999 geppetto limburgher tibbs|w
16:06:22 <abadger1999> racor: Hey, you're here I take it?
16:06:25 <abadger1999> #chair racor
16:06:25 <zodbot> Current chairs: RemiFedora SmootherFrOgZ abadger1999 geppetto limburgher racor tibbs|w
16:06:48 * racor is here (currently on the phone)
16:07:17 <abadger1999> k
16:07:59 * abadger1999 looks up the agenda
16:08:15 <abadger1999> I think we'll start with one easy thing and then discuss scls
16:08:23 <abadger1999> (in case langdon shows up by then)
16:08:52 <geppetto> sounds good :)
16:08:53 <langdon> abadger1999: im here...
16:09:06 <abadger1999> ah cool.
16:09:12 <abadger1999> Let's just dive into scls then
16:09:16 <abadger1999> #topic SCLs
16:09:36 <abadger1999> https://fedorahosted.org/fpc/ticket/339
16:09:56 <abadger1999> Meat of the guidelines: https://fedoraproject.org/wiki/User:Bkabrda/SCLGuidelinesDraft
16:10:25 <tibbs|w> First thing about the draft is that it doesn't even define SCL.
16:10:38 <abadger1999> Something supplemental that we might have some ideas about but should probably mostly take the form of feedback back to fesco: https://fedoraproject.org/wiki/User:Mmaslano/SCLinFedora
16:11:14 <tibbs|w> Second thing about it is that it makes no mention of when SCLs would be permitted and when they wouldn't.
16:11:35 <abadger1999> <nod>  Similar to the bundled library exceptions criteria?
16:11:39 <limburgher> In addition to all that, I really am not comfortable with it being in /opt/.
16:11:48 <tibbs|w> Yes, certainly can't be in /opt.
16:12:07 <tibbs|w> But they seem kind of fixed on that, judging on list discussion.
16:12:09 <limburgher> What about /usr/scl/ or possibly /usr/scl/<vendor>?
16:12:26 <RemiFedora> please no <vendor> part
16:12:45 <geppetto> langdon: How possible is it for scls to have "paths" so that it can default "write" to X … but "read" from X, Y or Z?
16:12:50 <abadger1999> Looking at the FHS portion on /opt that bkabrda pointed out, what is wrong with /opt/vendor ?
16:13:03 <limburgher> The main argument for /opt I've seen is "but it's not part of the distro" with which I disagree.
16:13:07 <tibbs|w> Maybe some non-fedora stuff might want to do that, but we need to keep distro-supplied things in the distro-owned directories.
16:13:23 <limburgher> tibbs|w: <nods>
16:14:35 * abadger1999 notes that if we go with /opt there are some other adjustments that may need to be made though -- FHS specifies /etc/opt and /var/opt for configuration and variable state data... I'm not sure that scls obey either of those.
16:14:53 <langdon> tibbs|w: limburgher i am confused about this.. why is it nec. "owned" by the distro? can't it be packaged by vendor x and hosted by fedora?
16:15:25 <langdon> like can't it be /opt/rh for a package that is distrib'd by fedora?
16:15:26 <tibbs|w> I don't even know how to address that.
16:15:29 <geppetto> abadger1999: But those aren't required, right? … you can just dump everything into a subtree of /opt too … Eg. /opt/foo/etc?
16:15:41 <abadger1999> geppetto: Let me read the exact wording again.
16:15:49 <geppetto> abadger1999: I mean … I guess a lot of the stuff that lives in /opt probably doesn't obey FHS anyway, so meh.
16:15:50 <limburgher> If we're discussing guidelines for something done in Fedora, then the product is part of Fedora.
16:15:53 <tibbs|w> If you have to twist the logic so far as to say that it matters who owns the package in Fedora, I just don't know what to say.
16:16:06 <tibbs|w> It's in the Fedora repository; it's part of Fedora.
16:16:22 <limburgher> If some third party wants to to XYZ in /opt, they can, but then it's not part of fedora.
16:16:23 * racor is back
16:16:33 <langdon> tibbs|w: ok.. i think i see what you mean.. the problem isn't opt it is that fedora owns the distro therefore opt is not "available" to fedora packages?
16:16:35 <abadger1999> Package files that are variable (change in normal operation) must be installed in /var/opt. See the section on /var/opt for more information.
16:16:37 <abadger1999> Host-specific configuration files must be installed in /etc/opt. See the section on /etc for more information.
16:16:51 <abadger1999> geppetto: so... looks like FHS says you can't just dump a subtree.
16:17:06 <geppetto> limburgher: So there are few things: 1) What paths the scl tools use by default when the user runs them. 2) What paths any scl created packages that Fedora ships use. 3) What paths any user scl created packages would want to use.
16:17:17 <geppetto> abadger1999: interesting, thanks.
16:17:28 <tibbs|w> The point of all of that is to ensure that the end user can do crazy stuff with their own packages and be guaranteed that the distro won't ever conflict with them.
16:17:29 <abadger1999> geppetto: I think they're aiming for /opt is an approved-for-third-party-vendors equivalent of /usr.
16:18:02 <limburgher> abadger1999:  RIght, but how is this third-party if it's part of Fedora?
16:19:26 <abadger1999> limburgher: <nod>  I can see that viewpoint.  OTOH, I think we are treading on a border here -- We're moving towards having a set of packages that we call a fedora product and another set of packages that we're going to call addons to that product.
16:19:46 <racor> c.f. http://www.pathname.com/fhs/pub/fhs-2.3.html#OPTADDONAPPLICATIONSOFTWAREPACKAGES
16:19:54 <abadger1999> They may both be produced by the fedora project but there is a distinction between the OS/distribution there and the addon.
16:20:09 <abadger1999> Which is different than what we've had in the past (even when there was core andextras)
16:20:18 <geppetto> abadger1999: We haven't even started moving yet though, just talking about moving … and even if we do move the addons aren't really "third party" in any good definition.
16:20:29 <langdon> abadger1999: i guess that was what i was thinking all along.. like this stuff is provided by fedora but is not "mainline" (w/c is hard here).. thats why i thought opt made sense
16:21:18 <geppetto> w/c == ?
16:21:28 <langdon> geppetto: sorry... editor speak, "word choice"
16:21:37 <geppetto> ahh, thanks.
16:22:13 <limburgher> abadger1999:  But just because it's pseudo-third-party doesn't mean it can't live inside FHS.
16:22:21 <geppetto> langdon: So one thing about that … do you imagine that scls in Fedora will likely be newer or older versions than what is the "mainline"?
16:22:22 <langdon> basically, i think of scls providing somehting that is different than what is "native to the distro" ... therefore "optional" (or "extra").. hence "/opt" makes sense to me
16:22:37 <limburgher> rpmfusion publishes things that are Fedora add-ons that live inside FHS.
16:22:53 <abadger1999> geppetto: <nod>  about we're still in the planning stage.  I'll note that "third party" was my word choice... it isn't in the FHS for /opt.
16:23:02 <langdon> geppetto: potentially both, in fedora-land, i would think "older" is maybe more common, but in centos-land/rhel-land, newer
16:23:27 <abadger1999> limburgher: Right -- but is this use of /opt within the FHS?  I kinda think it could be (with my notes about /etc/opt and /var/opt)
16:23:47 <limburgher> langdon:  But why is it needed?  What is the benefit of /opt/ over (for example) /usr/scl?
16:24:43 <langdon> limburgher: honestly, i think it is more logical ;) not implying that it is "native"
16:24:46 * abadger1999 notes that he's only 2/3 of the way through teh scl draft but it looks like an rpm-managed virtualenv to me (for people who have experience with python-virtualenv)
16:24:48 <limburgher> abadger1999:  I think we need to stay out of /opt mostly for practical reasons.  People rely on being able to do whatever crazy thing they want in /opt and not have the distro nuke it.  SCL in opt could easily break that expecation.
16:25:06 <racor> abadger1999: from the FHS: "Distributions may install software in /opt, but must not modify or delete software installed by the local system administrator without the assent of the local system administrator..."
16:25:07 <limburgher> langdon:  logical how?
16:25:33 <limburgher> racor:  Right, and since RPM ignores what it doesn't know about, we should stay out.
16:26:00 <geppetto> racor: The argument has been made that using yum/rpm to install things is "assent of the local system admin."
16:26:16 <racor> OK.
16:26:35 <langdon> limburgher: because you don't "need" these things and they are (potentially) conflicting with native. Like, why would a regular old fedora user need python 2.4 (making up an example)? you only need it because you are satisfying a special case
16:26:38 <limburgher> geppetto:  Putting the onus on us not to violate the admin's trust.
16:26:51 <geppetto> It's kind of a weird line though … because if using yum is assent, then the line is mostly meaningless … and if it isn't then it should just say "distro. doesn't touch anything under /opt"
16:26:54 <abadger1999> racor: but: A package to be installed in /opt must locate its static files in a separate /opt/<package> or /opt/<provider> directory tree, where <package> is a name that describes the software package and <provider> is the provider's LANANA registered name.
16:26:58 <limburgher> langdon: So put them in /usr/scl.
16:27:00 <langdon> limburgher: and "special" = "opt" in my head
16:27:20 <abadger1999> the <provider> clause in there is designed to give vendors (including us) a "safe" namespace.
16:27:44 <limburgher> langdon: We already allow for parallel installable stacks, by using different paths inside FHS.
16:27:48 <racor> abadger1999: Correct. I read this as, if fedora wants to install something into /opt, then into /opt/fedora.
16:27:57 * abadger1999 notes that if we do /opt we should get a Fedora LANANA registered name (right now, there's only Red hat registered names)
16:28:05 <abadger1999> racor: <nod>  I agree.
16:28:25 <limburgher> racor: If that's the case, why does the filesystem RPM not provide the /opt/fedora dir, as a warning?
16:28:45 <geppetto> One other good reason, IMO, to not ship packages in fedora which install into /opt is that people will often have a / and /usr mount point … so installing things into /opt will take away from their (often much smaller) / mount.
16:28:56 <abadger1999> limburgher: Could be oversight.
16:29:13 <abadger1999> (and my note about "fedora" not yet having a registered LANANA name)
16:29:44 <limburgher> abadger1999:  I can't be the only person who didn't know they should stay away from /opt/fedora/.
16:30:52 <langdon> limburgher: so, i see two problems with /usr/scl, 1) /usr implies native to me (but that is prob cause I am old) 2) scl implies that "scl" owns the packages which I think is weird because scl is just a style of rpm, not really anything "new" or anything that is a new "application" (per se)
16:30:58 <limburgher> Some people keep data there.  Some put code there.  Some use it for mount points.
16:31:17 <abadger1999> limburgher: <nod>  I can't argue with that.  Just weight it differently.
16:31:23 <abadger1999> (than you do)
16:32:03 <geppetto> langdon: I thought scl-utils had some commands so you could kind of look at an installed scl as though it was native?
16:32:08 <langdon> limburgher: they keep data or code or mnts in /opt? Maybe I am crazy... i only have ever put "software" there.. usually under a vendor
16:32:15 <limburgher> landgon:  So if it's nothing but another style of RPM provided by Fedora, why should it get to live in /opt?  Who cares if it's not the system version of something?  SOmetimes there is no system version of something.
16:32:45 <limburgher> langdon:  The point is that there has been the expectation that /opt is the admin's playground.
16:32:45 <langdon> geppetto: yes.. but just for an "app" not for the OS (unlike alternatives)
16:33:21 <racor> limburgher: because it's optional and so far unused?
16:33:23 <limburgher> langdon:  What is "app"  and what is "OS"
16:33:26 <geppetto> langdon: Right … so the idea of scl "owning" the scl packages is not that far from reality.
16:33:30 <Evolution> limburgher: I've never considered it a playground. most everything in my /opt is from a vendor package though. either HP, IBM, or similar.
16:33:36 <langdon> limburgher: sys-version) because it is not "tested" the same way, like it is not "known good" for the python scl to be used to run native anything..
16:34:13 <limburgher> Evolution:  That's fine.  That's one use case.
16:34:37 <geppetto> limburgher: App. is one or more packages … OS is the default version (Eg. when you type bash, what you get … vs. installing an older/newer bash as an scl).
16:34:45 <langdon> limburgher: admin's play) i guess I didn't know that expectation :) I always thought one used var or tmp or mnt for the things you are describing (or /usr for some apps)
16:34:56 * abadger1999 notes that we're at 30 minutes.  Do we want to continue to discuss the filesystem location or do we want to get to other issues?
16:35:08 <geppetto> abadger1999: lol
16:35:27 <geppetto> abadger1999: Might be useful to move on an talk a little about more than just the FS location :)
16:35:32 <racor> dumb question: Is scl about users composing "SCLs" or is it about Fedora composing "SCLs"?
16:35:44 <abadger1999> I already think we aren't going to vote on this today -- I hope we can at least get an idea of what things we want to get changed.
16:35:52 * langdon brb, changing network provider
16:35:56 <geppetto> abadger1999: for sure.
16:36:07 <geppetto> racor: both
16:36:34 <geppetto> racor: In theory users can already use it in Fedora … so the big feature is if we can allow people to ship "official" Fedora scl packages.
16:36:40 <abadger1999> racor: both.  I think the main discussion right now has focused on Fedora composing SCLs but I know from conferences that users have wanted something like this as well.
16:37:26 <RemiFedora> racor, I think guildelines is about what "fedora" provides. User can also build RPM ;) we don't have to care care of what user do.
16:37:32 <racor> geppetto: IMO, in case of the former, it would be suiteable to leave the choice of /opt/<...> to the user.
16:37:42 <geppetto> racor: right
16:37:55 <racor> geppetto: However I fail to see any sense in the latter.
16:38:09 <limburgher> RemiFedora:  RIght, users can make RPMS installed in /tmp for all I care. :)
16:38:55 <geppetto> racor: So … at the moment I don't really either (there are cases where it might be easier, I guess) … but if Fedora changes to have a core and addons, then I think it's much more viable.
16:39:30 <racor> geppetto: IMO, this core and addons is rubbish
16:40:04 <racor> geppetto: Fedora  is supposed to be a distro and as such there is no sense in dividing it
16:40:12 * langdon back
16:40:26 <geppetto> It's the only viable solution I've seen to the mess we have atm. where half the OS wants to go direct from git commits to packages in all releases and the other half is stuff I don't want broken.
16:40:50 * abadger1999 <nods> at geppetto's assessment
16:41:37 <racor> geppetto: In other words, it's Red Hat's plan to abandon Fedora
16:41:50 <tibbs|w> I wouldn't go that far.
16:42:17 <racor> tibbs|w: It's apparent all over the place
16:42:19 <geppetto> I'm not sure how you get those words from what I said.
16:42:36 <rbergeron> I'm pretty sure i'm not seeing how you are coming to that conclusion.
16:42:44 <racor> geppetto: I better shut up now, I am really upset and angry
16:42:50 <rbergeron> (sorry for barging in, will shut up if you want me to)
16:43:12 <limburgher> I can't imagine Red Hat doing something so colossally short-sighted and against their own self interest.
16:43:16 <tibbs|w> Oh, don't get me wrong; I think it's quite nuts but I don't see it as some kind of Red Hat conspiracy.
16:44:12 <geppetto> tibbs: you think the core+addons plan is nuts? why?
16:44:30 <geppetto> rbergeron: No, your calming input would be very welcome.
16:44:39 <tibbs|w> This is far from the place to discuss that.
16:45:08 <RemiFedora> tibbs|w, I agree
16:45:15 <geppetto> Well … as I said, I think for scls to be viable in Fedora when it has to depend on that, or something else that solves the same problems.
16:45:32 <rbergeron> Red Hat isn't abandoning Fedora. If nothing else, I think scl's, even if ew all may have some sort of "ewww" feeling here and there about them for various reasons,
16:45:41 <rbergeron> are an attempt to meet users and developers in the middle somewhere. Because otherwise,
16:46:04 <rbergeron> everyone is just going and sticking crap whereever they want anyways with whatever they pulled off of github yesterday, or using omnibus packages, or $variousothermethodologies.
16:46:31 <rbergeron> It may be an evolution and not permanent; I don't know. But i can assure you that we are part of that evolution, and we have the minds to make it work right.
16:46:36 <racor> limburgher: it's locking out the community and about re-implementing the RH vs. rest of the world  regime, I had hoped Fedora was aiming at overcoming.
16:46:36 <langdon> rbergeron: +10
16:46:42 <tibbs|w> The only way to maintain sanity here is for things to be extremely restricted, and this draft doesn't even attempt to touch on any of that.  It's really not in a state for us to consider except superficially (which is why we're hung up on the /opt thing).
16:46:44 <rbergeron> And we're not being abandoned.
16:47:07 <limburgher> racor:  I'm not sure I'm seeing that.
16:47:27 <tibbs|w> In any case, maybe we could actually do our job and critique the draft?
16:47:36 <racor> libburgher: I am having not doubts.
16:47:44 <rbergeron> racor: If you have listened to mattdm's talk, it's useful to note that the distinction about core vs. exras this time around is that core will not be "in house, red-hat controlled" as previously.
16:47:46 <racor> -2
16:47:48 <tibbs|w> It's not for us to actually discuss whether this is something Fedora wants; that's been decided elsewhere.
16:47:55 <limburgher> tibbs|w:  I, personally am hung up on /opt not because I object to SCLs, but because I'm in favor and care deeply that they be done properly.
16:47:59 * rbergeron notes we should move on per tibbs|w comment. err, you. :)
16:48:07 <abadger1999> racor: I had a similar thought of how that could come to pass last night -- but I also was thinking about how to avoid that.  I don't think the technology of scls or the plan of addons is in-and-of-itself going down that path.  It's what we create around it that will take us one way or the other.
16:48:28 <rbergeron> (since i am poorly equipped to do much technically here in this forum. thanks guys :D)
16:48:29 <tibbs|w> And anyway, this draft is simply terrible.
16:48:29 <limburgher> I think it's more a set of update policies than anything else.
16:48:36 <limburgher> thanks rbergeron!
16:49:10 * abadger1999 has been compiling his own list of problems with the draft this morning .
16:49:35 <abadger1999> I can add to it and then send it to the list if people want to give me more stuff.
16:50:08 * abadger1999 can also start making the draft better once he gets an idea of what's okay to change and what's technically infeasible.
16:50:41 <racor> rbergeron: I have read his proposal, but had considered it absurd management blurb, not worth being taken seriously
16:51:39 <racor> abadger1999: Can we please proceed, I don't think we can reach and progress on SCLs today
16:52:14 <abadger1999> <nod>  But in order to proceed at the next meeting we need to identify what things we are having problems with.
16:52:32 <abadger1999> so changes can be made over the course of the week.
16:53:12 <abadger1999> So I have down "Add a definition of SCLS" and "Work out the filesystem location" from the meeting so far.
16:53:21 <abadger1999> what else do people want to see changed?
16:53:38 <abadger1999> oh and "criteria for allowing something to be packaged as an scl"
16:53:49 * abadger1999 adds that to the list
16:54:00 <limburgher> Clarification of whether non SCL packages are allowed to Require or BuildRequire SCL packages, and if so, how to do so properly.
16:54:06 <RemiFedora> "criteria for allowing something to be packaged as an scl" => huge +1
16:54:44 <RemiFedora> limburgher, yes, I think I have already ask this on the ticket
16:55:09 * abadger1999 adds that
16:55:13 <limburgher> RemiFedora: Excellent.
16:56:27 <RemiFedora> Dealing With Automatic Provides/Requires => this part doesn't talk of library, and there is some problem if  a system package and a scl package provide the same library (same soname)
16:56:33 * nirik has some that might be more fesco related... like "how do scl updates fit into the updates policy"
16:57:13 <nirik> can/will parts of a SCL be updated incompatibly moving forward? or are they expected to not.
16:57:41 <nirik> is there a limit to the number of things in a SCL?
16:57:43 <abadger1999> RemiFedora: interesting, yeah -- I was thinking that the libraries wouldn't be in the standard linker path so they wouldn't be an auto-provides problem... but if that's so, then I'm not sure how auto-requires works.
16:58:06 * racor thinks about conflicting binaries (same name, different path)
16:58:12 * abadger1999 adds "how do auto provides and requires for elf libraries work?"
16:58:45 <langdon> nirik: thinking no (new scl for changes) and no
16:58:46 <abadger1999> racor: for programs it looks like what happens is: User runs he SCLs enable script.
16:59:10 <racor> racor adds how do all non-path prefixed provides/requires work
16:59:16 <abadger1999> racor: from that point forward the user's PATH is updated to put the SCL's bindir before the normal bindir.
16:59:24 <nirik> so once a scl is created it's bugfixes/minor changes, and anything else would just be a new scl?
16:59:46 <abadger1999> so things that use $PATH instead of an explicit full path name will use the scl version.
16:59:55 <geppetto> nirik: mostly, yes.
17:00:00 <langdon> nirik: well.... maybe backward compat.. but essentially, yes
17:00:03 <jreznik> guys, how long will fpc meeting take? I did not see it in the wiki, so I planned go/no-go meeting (in one minute), we can move to #fedora-meeting-2 if needed, just asking
17:00:07 * nirik notes go/no-go meeting is scheduled in here in a few.
17:00:08 <racor> abadger1999: Things aren't as trivial as you might think: e.g. 5 different gccs installed in parallel
17:00:45 <abadger1999> langdon: I have that on my list of possible problems in a different way. (re: updates, freezing of scl, etc)
17:00:48 <geppetto> jreznik: probably better to move it, if you can
17:01:16 <racor> abadger1999: Consider long chains of indirect deps (e.g. which "sh", "perl" will be used)
17:01:19 <abadger1999> jreznik: if you can't we can end this I guess... it's been productive but it'll go on to next week as well.
17:01:45 <jreznik> we'll move
17:01:54 <abadger1999> racor: yep.  there is some huge limitations built in.
17:02:17 <racor> abadger1999: I say short sighted rubbish
17:02:27 <abadger1999> racor: can you solve it?
17:02:30 <RemiFedora> abadger1999, for your list, my comment #18 about noarch metapackage have no answer, so can you add it please
17:02:47 <nirik> GO/NO-Go for F20 alpha is in #fedora-meeting-2 now <----
17:03:09 * abadger1999 catches up on the list of things to discuss
17:03:18 <racor> abadger1999: No, I can't ... to me this undertaking is a plan which has failed before it begun.
17:05:28 <geppetto> abadger1999: A minor thing: I'm not happy with the stuff before %scl_install in the example .spec … seems like that should be in some macro, or give a reason why everyone needs to copy&paste it.
17:06:10 <geppetto> abadger1999: A more serious thing: Needs a lot more wording around Requires on non-scl packages, as those can act like conflicts in some situations.
17:06:13 <abadger1999> RemiFedora: both of your comments in #18 were not addressed or only the first (metapackages) ?
17:06:13 <RemiFedora> geppetto, probably because all SCL oesn't need all those lines
17:06:25 <RemiFedora> abadger1999, the one about bnoarch
17:06:28 <abadger1999> k
17:07:27 <geppetto> RemiFedora: Yeh, but I'd rather see: %_scl_add_path \n %_scl_add_ld_library_path \n %_sc_add_manpath
17:07:54 <RemiFedora> geppetto, ok
17:08:11 <geppetto> just seems prone to error, when the lines will be identical for packages that need them.
17:08:19 <RemiFedora> and I think there is quite ambiguous part for requires (a SCL package) according if we are in a non-scl, in the same scl or in another SCL (also my comment # 18, sorry)
17:08:44 <abadger1999> RemiFedora: You are referring to things like /opt/rht/python33/usr/lib64/ <= correct?
17:08:50 <RemiFedora> yes
17:08:51 * abadger1999 wants to get his question correct
17:08:53 <abadger1999> Cool.
17:09:33 <RemiFedora> perhaps metapackage could be "noarch" if all the packages in the SCL are noarch... but I think it won't ever build... (on a 64bits builder)
17:13:00 <abadger1999> geppetto: Do you have an example for me to use with Requires on non-scl packages can act as conflicts?
17:13:56 <geppetto> abadger1999: The obvious problem would be something like: Requires: foo = 1.2.3 … where the scl package is the only thing keeping foo back at that version.
17:14:18 <geppetto> abadger1999: So you can't update "the OS" without updaing the scl.
17:15:37 <geppetto> abadger1999: I think the general wording has to be heavily in the "yes, you can require non-scl stuff … but you have to be very general in your requirements, and if you need something that might be updated you have to scl bundle it"
17:15:37 <abadger1999> Cool.
17:16:02 <abadger1999> geppetto: or be okay with rebuilding the scl for that?
17:16:40 <geppetto> Well, maybe … it depends … in theory the idea of scls are that they don't interact with the OS in that kind of way … hence why you can't conflict with parts of the OS.
17:16:42 * abadger1999 kinda thinks there will be a split between scls inside of Fedora Commons and scls in the "SCL Addon Repositories" here.
17:17:14 <abadger1999> <nod>
17:17:19 * abadger1999 add this
17:20:20 * racor mumbles daemons/services
17:21:25 <abadger1999> that is interesting as the rest of the draft seems to implicitly assume the "base" package is the root of the dependency tree as well.
17:21:41 <abadger1999> I wonder if there will be any fallout from this.
17:21:48 <abadger1999> Okay -- anyhting else?
17:23:08 <RemiFedora> abadger1999, I think the "runtime" package is more the first one, required by all others packages in the collection (the metapackage, is only.... a metapackage... to make installation easier)
17:23:09 <langdon> geppetto: i think you are right on.. and, in a sense, an scl author should err on the side of more "bundling" vs a normal rpm
17:23:51 <abadger1999> langdon: My notes on issues are really rough -- Do you want to get together with me to go over them (say tomorrow?) or is it better to send the notes in all their unclear glory to the packaging list and then we try and clarify them after they're out there?
17:23:53 <langdon> RemiFedora: i would agree
17:24:15 <geppetto> langdon: Yeh, I mean there are things like an scl using /bin/bash or having a dep. on libc that it's just a waste to bundle … but it quickly gets more complicated.
17:24:17 <limburgher> langdon:  Why?
17:24:27 <langdon> abadger1999: i am happy to work on them with you (and cleanliness might lead to efficiency ;) )
17:24:32 <abadger1999> yeah :-)
17:24:43 <langdon> limburgher: why, which?
17:25:09 <RemiFedora> abadger1999, langdon probably I can also help you
17:25:23 <limburgher> langdon:  Why bundle, why not have packages of deps as part of the SCL?
17:25:26 * RemiFedora have some experience playing with scl...
17:25:42 <abadger1999> RemiFedora: k.  We'll need to take over/make a new channel tomorrow to discuss then.
17:25:53 <abadger1999> new transient channel :-)
17:26:11 <geppetto> limburgher: Because then installing the scl can involve changing "the OS", and/or keeping it installed can affect upgrading "the OS".
17:26:16 <RemiFedora> just ping me on #fedora-devel
17:26:38 <geppetto> limburgher: And one of the points of SCL is that it doesn't do either of those things.
17:26:42 <limburgher> geppetto:  If the dep RPM in the scl doesn't conflict with "the OS", it shouldn't
17:27:09 <RemiFedora> SCL me stay "transparent" for the system, I think, else it's a bug
17:27:17 <abadger1999> limburgher: I think that "bundle" was in quotes because it's not true-bundling.  Its a separate package within the SCL.  But it's a duplicate of the package that's on the system already.
17:27:26 <langdon> limburgher: i think we may be mixing terms here.. i was using "bundle" very loosely.. like "it is in the scl, but not in the same rpm" ...
17:27:39 <RemiFedora> but of course the SCL can use stuff in the system, so as usually need to be rebuild if something change in the system
17:27:40 <limburgher> abadger1999:  That's what I was hoping was the case.
17:27:44 <geppetto> limburgher: But, again requires and conflicts are two sides to the same coin … conflicts: foo < 2 … requires: foo >= 2
17:27:45 <langdon> limburgher: it is hard to say "correctly"
17:28:00 <limburgher> langdon:  But important. ;)
17:28:09 <langdon> limburgher: very
17:28:35 <abadger1999> Okay, anything else people want to put on the table?
17:28:37 <langdon> geppetto: and.. you start to think about scls being portable across distros and it gets even more fun :)
17:28:59 <abadger1999> langdon: You make me cry.
17:29:02 <abadger1999> ;-)
17:29:03 <geppetto> langdon: Yeh, at that point "scl bundle" everything is the only real option.
17:29:04 * RemiFedora is hungry
17:29:08 <langdon> geppetto: just like java, write once, debug everywhere :0
17:29:43 * langdon finger dragged on the shift key
17:29:47 <SmootherFrOgZ> abadger1999: nothing else here.
17:30:44 <abadger1999> Alright if there's nothing else, Let's close this, I'll get these notes into slightly better shape with langdon and RemiFedora on IRC tomorrow same-time-ish.  Then send to packaging@lists.fp.o for discussion.
17:30:54 <abadger1999> Try and make the draft better for next week.
17:31:23 <abadger1999> I think we may want to do one or two other tickets next week and then dive back into scls ;-)
17:31:56 * abadger1999 notes we can also discuss and vote on those other tickets *in the ticket* during the week.
17:32:01 <abadger1999> :-)
17:32:26 <abadger1999> alright closing in a minute.
17:33:35 <abadger1999> #endmeeting