16:11:40 <abadger1999> #startmeeting fpc
16:11:40 <zodbot> Meeting started Thu Nov  7 16:11:40 2013 UTC.  The chair is abadger1999. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:11:40 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:11:50 <abadger1999> #topic SCL Draft discussion
16:12:02 <racor> abadger1999: I seriously think this SCL stuff has not evolved sufficently to be our (FPC) subject.
16:12:06 <abadger1999> I've finished the retirement section: https://fedoraproject.org/wiki/User:Toshio/SCL_Guidelines_(draft)#SCL_Retirement
16:12:53 <limburgher> It looks rational to me.
16:12:55 <abadger1999> racor: the issue I would see is that if we don't work on it then it will either never evolve or will evolve in a direction that we won't be able to use because it violates a bunch of fedora packaging foundations.
16:13:32 <limburgher> abadger1999:  Or as I put it last time, we may not want it done, but we need to make sure it's done intelligently.
16:13:47 <abadger1999> and I'm willing to do the work... it's just slow since it's just me and it seems that even the things I think are common sense changes aren't accepted right off the bat by the scl team.
16:13:53 <abadger1999> limburgher: yep.
16:14:17 <geppetto> abadger1999: How has the retirement section changed since last week?
16:14:46 <geppetto> The first bit doeesn't seem familiar
16:14:58 <abadger1999> geppetto: polishing and organization -- in terms of meaning, I took your suggestion about the length of time.
16:15:07 * geppetto nodsx
16:15:10 <abadger1999> planned retirement?
16:15:20 <abadger1999> That was there but lower down in the section before.
16:15:24 <geppetto> Ahh
16:15:47 <geppetto> Just the bit about needing to explicitly say you'd commit to maintaining it each release seemed unfamiliar.
16:16:04 <abadger1999> <nod>
16:16:26 <abadger1999> If you don't think it's a good idea, I'm open to discussing and changing it :-)
16:16:34 <geppetto> I don't mind it :)
16:16:37 <racor> abadger1999: Currently the SCL stuff is taking away FPC resources without end and effectively paralyzing FPC.
16:16:39 <abadger1999> I've only discussed it once with some people.
16:16:45 <geppetto> I'm just not sure what people wanting to do SCLs will think.
16:17:39 <geppetto> racor: If we get qurom I'm more than happy to look at some normal tickets today, was hoping to do it last week too but it didn't happen.
16:18:30 <geppetto> racor: I do think it's better if we spend some time on SCLs each week, rather than leaving them for N weeks … but I'm open minded on that.
16:19:14 <geppetto> Atm. we are in FPC pre-time anyway … so it's kind of free ;)
16:19:30 <abadger1999> <nod>
16:21:13 <abadger1999> so the part about explicit maintainance... I put in to try to minimize the times when we'd be removing SCLs due to unanswered security bugs.
16:21:33 <abadger1999> Those removals have less lead time so they're more disruptive.
16:21:53 <abadger1999> That does bring up the question about retirement in released Fedora, though.
16:22:07 <abadger1999> Do we want to do that or not?
16:22:47 <abadger1999> on the one hand, security risk until that fedora release goes EOL.  OTOH, break deployed systems that depend on the SCL/general scl package being pulled.
16:23:48 <geppetto> How would that work?
16:24:11 <abadger1999> the mechanics of retiring in released fedora?
16:24:23 <geppetto> Yeh. We can't remove anything from the release isos or the /release/ repos.
16:24:26 <abadger1999> every scl installed will pull in the $scl-runtime package.
16:25:17 <abadger1999> So on user's systems, if that package has an Obsoletes on the general scl packages we want to get rid of, they won't be able to install it.
16:25:27 <abadger1999> and it would be removed when the -runtime package gets updated.
16:25:32 <geppetto> True
16:25:48 <abadger1999> release repos and iso would remain a problem if people don't update.
16:26:15 <abadger1999> but that's true of any issue in there.
16:26:43 <abadger1999> I just don't know if it's a good idea :-)
16:27:13 <geppetto> yeh, I'm not sure either … I can't see many users being happy about having an upgrade remove something they'd installed/used.
16:27:42 <abadger1999> <nod>
16:28:05 <geppetto> If we could somehow stop people from installing it, but allow people to keep it that already have it … that would probably be the best, although still full of suck.
16:28:15 <abadger1999> I guess I should err on the side of "expectation that already exists for mainstream packages" then.
16:28:18 <geppetto> Ideally we won't have to deal with it ;)
16:28:29 * RemiFedora is back
16:28:41 <abadger1999> *cough*optimism[..]*cough* ;-)
16:28:50 <geppetto> Yeh, if the worst came to the worst … what would we do about a random package with a security problem?
16:29:44 <geppetto> My guess is enough interested people would be dragged in until we had something that at least made it a minor/local security problem and then we'd remove it for the next release.
16:30:10 <abadger1999> supposedly provenpackagers will fix it.  I think in practice, that's happened maybe 25% of the time and the rest of the time it just sits until it gets dropped in a per-release ftbfs/retire orphans cycle.
16:30:45 <abadger1999> <nod>  yeah.
16:32:38 <geppetto> I guess it doesn't hurt to say we _may_ remove an SCL without a release, using obsoletes, I just think that it'd have to be the last resort to do that.
16:32:50 <geppetto> s/without/within/
16:33:40 <abadger1999> <nod>
16:36:05 <abadger1999> heh -- this could be used abusively to get other people to create security bugfixes for an SCL package that you're unprepared to fully maintain but I hope fesco/whoever is called on to adjudicate that would do the right thing.
16:37:57 <abadger1999> okay, retirement section updated.
16:39:49 <abadger1999> scl questions I'd like answered today: (1) approve retirement (2) was anyone persuaded by notting's argument about /opt being a mountpoint that sysadmins already are dealing with (3) dots in the version or not?
16:40:09 <limburgher> Unexpectedly back for the next 20 minutes.
16:40:41 <abadger1999> woo hoo!
16:40:51 <abadger1999> #chair geppetto limburgher RemiFedora racor
16:40:51 <zodbot> Current chairs: RemiFedora abadger1999 geppetto limburgher racor
16:41:03 <RemiFedora> small quorum
16:41:17 <abadger1999> Smoother1rOgZ: FPC has quorum now if you are aroung to join.
16:41:39 <geppetto> #1 +1
16:41:46 <geppetto> #3 yes
16:42:23 <abadger1999> #topic approve the Retirement section of the SCL Draft
16:42:32 <abadger1999> https://fedoraproject.org/wiki/User:Toshio/SCL_Guidelines_(draft)#SCL_Retirement
16:42:45 <RemiFedora> +1 for current wording
16:42:46 <abadger1999> last week we approved the other portions of the SCL Approval Section.
16:42:52 <limburgher> +1 as well
16:42:58 <abadger1999> This is the last section of that (which needed polish last week)
16:42:59 <abadger1999> +1
16:43:14 <abadger1999> We're at +4.
16:43:22 <abadger1999> #chair tibbs|w
16:43:22 <zodbot> Current chairs: RemiFedora abadger1999 geppetto limburgher racor tibbs|w
16:43:28 <abadger1999> Hey, we started early.
16:43:33 <tibbs|w> Hmm.
16:43:40 <tibbs|w> Did I miss a time change?
16:43:43 <abadger1999> tibbs|w: We're discussing approving https://fedoraproject.org/wiki/User:Toshio/SCL_Guidelines_(draft)#SCL_Retirement right now.
16:44:10 <abadger1999> tibbs|w: the time changed but we started early because some people have to leave early today.
16:44:17 <abadger1999> (time changed to 17:00 UTC)
16:44:46 <abadger1999> tibbs|w: So far we have +4 to approve the SCL Retirement section.
16:45:08 <tibbs|w> Yeah, I thought we changed so the real time didn't change.  This is about as early as I can be available on a Thursday.
16:45:17 <abadger1999> Smoother1rOgZ, racor, you can also vote on that section if you like.
16:45:42 <abadger1999> tibbs|w: <nod>  Next week we'll start at 17:00 (so in 15 minutes)
16:46:10 <tibbs|w> +1 to that section
16:46:27 <tibbs|w> I guess you can bikeshed the times, but 2 months seems reasonable.
16:46:33 <abadger1999> #info retirement section of SCL draft approved (+1:5, 0:0, -1:0)
16:46:37 <abadger1999> <nod>
16:47:03 <abadger1999> 3topic filesystem location
16:47:07 <abadger1999> #topic filesystem location
16:47:16 <abadger1999> So the only thing I saw new here was notting's post.
16:47:54 <abadger1999> https://lists.fedoraproject.org/pipermail/packaging/2013-November/009728.html
16:47:59 <tibbs|w> I still say "can't be in opt" but people seem to have decided that even though SCLs are part of Fedora, they aren't part of Fedora.
16:48:08 <abadger1999> Did that change anyone's mind or are we still set against opt?
16:48:19 <abadger1999> <nod>
16:48:33 <tibbs|w> I mean, I'm seeing the argument that even though we're shipping them, they aren't part of the OS.
16:48:38 <tibbs|w> And I just don't understand that.
16:48:40 <abadger1999> That's fine. I jsut wanted to confirm that I should forge ahead with the assumption that they'll live in /usr/scl
16:49:01 <limburgher> I'm with tibbs|w.
16:49:01 <RemiFedora> as I wrote, I also prefer /opt
16:49:20 <tibbs|w> If they aren't part of the OS then why do we need to go through all of this?  Someone can make their own group to deliver this stuff and keep it out of Fedora and everyone will be happy.
16:49:37 <abadger1999> I can see the argument -- they are independent from the OS in that the idea is that their presence or absence doesn't affect the OS itself.
16:49:55 <abadger1999> We're going through this because Fedora as a project wants to ship them.
16:50:14 <abadger1999> and currently we're the group that decides on rpm packaging standards.
16:50:21 <abadger1999> so it goes through us.
16:50:26 <geppetto> abadger1999: I can see the argument for /opt for third parties … and them having everything under that one root
16:50:35 <geppetto> abadger1999: I'm less convinced about anything that Fedora ships
16:50:39 <tibbs|w> They they can't argue that they aren't the OS.  That's my sole point.
16:50:40 <abadger1999> <nod>
16:51:30 <geppetto> I think the argument for stuff Fedora ships is basically "it'd be really nice if they looked the same, if they come from Fedora or random third party"
16:51:55 <tibbs|w> And that's kind of a specious argument.
16:52:01 <tibbs|w> We can't control what random third parties do.
16:52:10 <abadger1999> Okay, sounds like no one's changed their minds so that's fine. I'll continue to work on the draft with filesystem location being /usr/scl.
16:52:28 <abadger1999> #topic dots in version portion
16:52:28 <geppetto> Which I do kind of agree with … but I'm not sure it's enough to break the world.
16:52:42 <geppetto> tibbs|w: yeh
16:52:55 <abadger1999> So mmaslano doesn't like dots in the version portion of an scl name.
16:53:00 <geppetto> abadger1999: I'm +1 on this … I see no reason to much everything together and make it less readable
16:53:07 <abadger1999> For me they make the version more readable.
16:53:20 <geppetto> What's her argument for not having dots?
16:53:32 <abadger1999> The argument I've seen is just that current scls for RHEL are dotless.
16:53:32 <limburgher> What would the dots to to tools that parse NEVR?
16:53:47 <abadger1999> If someone's seen another argument than that, please speak up :-)
16:53:51 <limburgher> s/to to/do to/
16:53:55 <abadger1999> limburgher: nothing.
16:54:04 <abadger1999> We already allow dots for compat versioning.
16:54:09 <limburgher> Cool.
16:54:40 <abadger1999> Okay, if no one knows of an argument, I'll mke hte proposal
16:54:49 <racor> abadger1999: my vote 0.
16:54:52 <abadger1999> Proposal: Version strings i nthe SCL name must use dots.
16:55:00 <geppetto> +1
16:55:01 <abadger1999> +1
16:55:12 <limburgher> +1
16:55:41 <abadger1999> racor: that was for the retirement section, correct?
16:56:22 <abadger1999> tibbs|w, RemiFedora, racor: we would need two more +1's for the question of dots in version.
16:56:37 <tibbs|w> +1 for the dot proposal.
16:56:54 <tibbs|w> It's ambiguous otherwise, and that's a bad thing.
16:57:30 <geppetto> tibbs|w: yeh, it works ok if you always have XY … which I assume is the case atm. … but will break down real fast as the real world hits it
16:58:25 <abadger1999> We're at +4.  Need one more.
16:58:52 <racor> abadger1999: yes, the retirement section. Actually I think this all is too uncooked to be voteable and is not our business.
16:58:52 <RemiFedora> I don't really care, and name are already so awful...
16:59:01 <abadger1999> k
16:59:33 <abadger1999> RemiFedora: heh.  So would you be willing to +1?  Or should I take it to the ticket to look for one more vote?
16:59:56 <RemiFedora> +1 to have some progress on SCL guildelines which seems so stalled
17:00:35 <abadger1999> #info Agreed that the version portion of scl names must include dots. (+1:5, 0:1, -1:0)
17:01:01 <abadger1999> racor: I took your comment to mean you vote 0 on this a well.  If that's inaccurateI can change that.
17:01:09 <abadger1999> Okay, moving on to other topics
17:01:12 <racor> RemiFedora: +1 to not having SCLs in Fedora ;)
17:01:27 <abadger1999> #topic #352     BLAS and LAPACK packaging
17:01:32 <abadger1999> https://fedorahosted.org/fpc/ticket/352
17:01:43 <abadger1999> We were waiting on spot and we still don't have input from him.
17:01:47 <abadger1999> Defer again?
17:01:52 <RemiFedora> racor, probably you don't know my real feeling ;)
17:02:04 <racor> abadger1999: Correct, but you can easily have a -1 on this if you prefer - To me all this is a waste of time
17:03:21 <racor> RemiFedora: probably, you so far only heard the polite version of my feelings, my real feeling about this are much more negative :)
17:03:43 * abadger1999 takes silence to be consent to defer on BLAS/LAPACK
17:03:48 <geppetto> yeh
17:03:51 <RemiFedora> yes
17:04:29 <abadger1999> #info deferred BLAS LAPACK discussion waiting on spot's input
17:04:40 <abadger1999> #topic #355     How to package noarch packages which require a binary dependency which doesn't build on all archs?
17:04:45 <abadger1999> https://fedorahosted.org/fpc/ticket/355
17:06:02 <abadger1999> I think we should have guidelines here.
17:06:05 <abadger1999> But there's no draft.
17:07:38 <abadger1999> What  nodejs has done and is documented here: https://lists.fedoraproject.org/pipermail/nodejs/2013-June/000039.html
17:07:40 <geppetto> we probably even need two
17:07:53 <abadger1999> Could be worked into a draft fairly easily but it does not address BuildRequires.
17:07:55 <geppetto> One for missing buildreqs, and one for missing reqs.
17:08:05 <abadger1999> yeah.
17:08:22 <abadger1999> #chair Rathann
17:08:22 <zodbot> Current chairs: Rathann RemiFedora abadger1999 geppetto limburgher racor tibbs|w
17:08:30 <Rathann> hi
17:09:10 <Rathann> sorry, a little busy around here and I might need to disappear for 15 minutes or so soon
17:09:55 <abadger1999> So for missing BuildRequires and for missing Requires that are annoying (like, the other package *only* builds on x86_64) we just need to add that the package needs to be arched, right?
17:10:02 <tibbs|w> Without infrastructure or rpm or something like that helping us out here, I guess we could always just say that such things aren't noarch, but that complicates other things.
17:10:15 <abadger1999> If so, I'll write up the draft this week.
17:10:36 * abadger1999 has time to write it, just doesn't have time to experiment to prove what works.
17:11:11 <geppetto> Yeh, I guess, treat it the same as a noarch package that needs an arched requires … sorry, you lose, needs to be arched.
17:11:22 <RemiFedora> abadger1999, yes I think if dependency are arch specific, the main package must be arched (and perhaps noarch stuff moved to a noarch-sub-package if it make sense)
17:12:22 <RemiFedora> I have 1 package I should change this way (it strongly requires dmidecode)
17:14:08 <abadger1999> ah .. .that would be an option as well -- similar to mattdm 's third option ( a stub package)
17:15:00 <abadger1999> still only applies to the Requires side, not to BuildRequires.
17:15:08 <RemiFedora> yes
17:16:10 <abadger1999> I think making the package arch'd is simpler.. so if it's okay, I'll write that up rather than this third option.
17:16:20 <abadger1999> I'll have a section for Requires and a spearate one for BuildRequires.
17:17:03 <abadger1999> #action abadger1999 to write a draft based on the nodejs strategy that also accounts for BuildRequires
17:17:33 <abadger1999> matdm also has a question I think is a no-brainer: "So, for a package where this isn't a problem on all Fedora primary archs, would it be okay to do the normal noarch thing in Fedora but make the package binary and use ExcludeArch? on the EPEL branch (where PPC is primary)?"
17:17:49 <abadger1999> I think that's a yes, that's okay to do.
17:18:04 <RemiFedora> yes
17:18:05 <abadger1999> It would even be okay between Fedor versions.
17:18:27 <geppetto> yeh, although the normal versions need to use obsoletes for the arch change.
17:18:34 <RemiFedora> hmm... ppc is still secondary arch
17:18:38 <abadger1999> ah, good point.
17:19:18 <abadger1999> geppetto: Do you know off hand what the obsoletes look like?
17:20:18 <geppetto> abadger1999: Obsoletes: %{name} < %{version}
17:20:23 <geppetto> roughly
17:20:35 * Rathann will be back in 20
17:20:51 <abadger1999> geppetto: <nod> taking into account the former package's disttag right?
17:21:29 <geppetto> Well, I'm assuming that the version gains at least one … yeh. I guess you shouldn't assume that for an example so …
17:21:35 <geppetto> abadger1999: Obsoletes: %{name} < %{version}-%{release}
17:22:11 <abadger1999> Cool.  I'll update the ticket with that info.
17:22:28 <abadger1999> #topic #357     time-api prior to openJDK8
17:22:36 <abadger1999> dhttps://fedorahosted.org/fpc/ticket/357
17:22:39 <RemiFedora> with  Obsoletes: %{name} < %{version}-%{release} each update will replace instead of update ?
17:23:05 <geppetto> RemiFedora: Yeh, that's just the general form … most people will make the right hand side the specific version where the arch changed.
17:23:11 <RemiFedora> isn't beter:  Obsoletes: %{name} <= %{lastnoarchversion}-%{lastnoarchrel}
17:23:13 <geppetto> RemiFedora: So you only get one obsoletes update.
17:23:38 <geppetto> RemiFedora: Yeh, but then you have to fill in the blanks.
17:23:46 <RemiFedora> or rather  Obsoletes: %{name} < %{firstarchedversion}-%{firstarchrel}
17:23:59 <limburgher> Back for like 4 minutes, anything you need me to read and vote on quickly?
17:24:18 <geppetto> limburgher: https://fedorahosted.org/fpc/ticket/357
17:25:06 <abadger1999> This is a reverse-bundling ticket.
17:25:07 <geppetto> Seems like a simple … *sigh* java +1
17:25:10 <abadger1999> We have one other like it.
17:25:15 <limburgher> Yeah, +1
17:25:36 <abadger1999> https://fedorahosted.org/fpc/ticket/248
17:26:13 <abadger1999> I'm +1
17:26:20 <RemiFedora> +1
17:26:28 <limburgher> +1 as well.
17:26:41 <geppetto> abadger1999: That one seems different, in that there was no time limit/etc.
17:26:52 <abadger1999> As general practice - shall we sy Reverse Bundling is okay but you need toask the FPC to get a Virtual Provides to track it?
17:26:56 <geppetto> abadger1999: Also no giant user pushing for it.
17:27:16 <geppetto> abadger1999: I'd say timed reverse bundling is fine, for backwards compat.
17:27:38 <abadger1999> true... but  if time is the key here, then we need to have a time limit in this java ticket.
17:27:59 <geppetto> abadger1999: They already said "for openjdk-7"
17:28:21 <geppetto> Not sure how easily it is for anyone to map that to fedora releases.
17:28:29 <abadger1999> They aren't stating when whadoop will move to openjdk8
17:28:51 <abadger1999> it may never move to openjdk-8 :-)
17:29:25 <geppetto> I was kind of assuming that it would be easy to do so, and they'd want to do it quickly … not like it'd be some py3k thing ;)
17:29:34 <abadger1999> <nod>
17:29:47 <geppetto> but I know almost nothing about java
17:31:03 <abadger1999> How about just: reverse bundling is fine for backwards compat?
17:31:24 <geppetto> sure
17:31:50 <abadger1999> Proposal: add to the bundled library guidelines: Reversed bundling is okay for backwards compat
17:31:52 <abadger1999> +1
17:31:56 <geppetto> +1
17:32:10 <RemiFedora> +1
17:32:14 <racor> Sorry, I need to quit for at least some 10 minutes, not sure if can make it back
17:32:24 <abadger1999> racor: okay.  Thanks for coming!
17:33:36 <abadger1999> limburgher, Rathann, tibbs|w: need two more +1's for this general rule to pass.
17:34:24 <abadger1999> (Which can then be applied to the specific time-api case)
17:34:32 <tibbs|w> Sorry, work.
17:34:41 <abadger1999> no problem.
17:34:55 <tibbs|w> As long as we can define reverse bundling well enough that it isn't confusing, +1 from me.
17:35:19 <tibbs|w> It appears to be what we pretty much demand most of the time anyway.
17:36:35 <tibbs|w> Unless I've become confused, that is.
17:38:03 <abadger1999> Something like: "reverse bundling is forking a portion of an upstream codebase into its own, separate Fedora package.  When done for purposes of adding a backwards compat API for use by another package this is okay.  Be sure to keep the forked code up to date with regard to the package it comes from."
17:38:32 <abadger1999> "apply to the FPC for a virtual Provide to use for tracking purposes"
17:38:42 <tibbs|w> Seems OK to me.
17:39:03 <abadger1999> Okay, I'll ask for one more +1 in the ticket.
17:39:47 <abadger1999> #info General Guideline allowing Reverse Bundling for backwards compat will finish voting in ticket (+1:4, 0:0, -1:0)
17:40:13 <abadger1999> We seem to have lost quorum for now.
17:40:40 <abadger1999> #topic Open Floor
17:41:05 <tibbs|w> I'm just happy something besides SCLs got some time.
17:41:08 <abadger1999> Are there tickets or issues or mailing list posts, etc that people want to bring up?
17:41:14 <abadger1999> Yeah, yay!
17:41:31 <abadger1999> I think SCLs will work better if I just bring discrete chunks every week to be voted.
17:41:43 <geppetto> yeh, seems to be working well so far.
17:41:50 <RemiFedora> yes (and big thanks for your work on the draft)
17:42:26 <abadger1999> No problem.  I've got to fill up my day somehow ;-)
17:42:36 <RemiFedora> abadger1999, I had no feedback for my proposal about "single vendor" SCL
17:42:57 <abadger1999> that was your last reply to mmaslano on one of hte threads, right?
17:43:00 * abadger1999 grabsa link
17:43:36 <RemiFedora> "All the package in a collection must use the same vendor. Package cannot extends collection of other vendor."
17:43:51 <abadger1999> This one: https://lists.fedoraproject.org/pipermail/packaging/2013-November/009753.html
17:43:53 <RemiFedora> of course no problem for Fedora.
17:43:54 <abadger1999> yeah.
17:44:21 <RemiFedora> this is probably EPEL specific
17:45:19 <RemiFedora> as soon as we have a <vendor> part in the path, we cannot extend a collection where main package use another <vendor>
17:45:50 <geppetto> yeh, that seems sane.
17:46:07 <geppetto> no point in having a namespace if you allow people to randomly trample over it.
17:46:28 <RemiFedora> (which also means, it's drop 99% of my interest for SCL... but well...)
17:46:33 <abadger1999> Hmm...
17:46:42 <abadger1999> I think we had several ideas.
17:46:53 <abadger1999> to include vendor
17:47:00 <abadger1999> one was in the directory names
17:47:07 <abadger1999> another was in the scl package names
17:48:37 <abadger1999> From reading the bug report that mmaslano linked to, I thought upstream was thinking that scl package name was the way to go?
17:48:54 <abadger1999> which would mean something like
17:49:10 <abadger1999> sclrootdir: /usr/scl/
17:49:39 <abadger1999> scls install into /usr/scl/rht-ruby1.9.3  and /usr/scl/fdr-ruby1.9.3
17:49:40 <geppetto> RemiFedora: Why do you want to extend another SCL?
17:50:03 <RemiFedora> use case: php54 in RHSCL, php extension in EPEL
17:50:35 <geppetto> RemiFedora: Blah … I guess in that case the SCL owner would explicitly support that usage?
17:50:53 <geppetto> And give compat. guarantees
17:51:18 <RemiFedora> but, these extension have to use which vendor ?
17:51:19 <geppetto> Seems kind of useless to provide a php5.4 SCL if people can't use modules for it.
17:51:33 <RemiFedora> geppetto, it works, for a single vendor
17:51:55 <abadger1999> RemiFedora: they would have to use the vendor of hte scl.
17:52:08 <tibbs|w> If you just provided a php5.4 compat package, people could package modules for it all they wanted.
17:52:30 <RemiFedora> abadger1999, php54 in RHSCL => extension in /opt/rh/....
17:52:37 * Rathann is back
17:52:38 <abadger1999> so if we're using directory names to include vendor then it would need to be set in the general scl package's spec file.
17:52:39 <tibbs|w> But I guess I'm just still missing the whole SCL thing entirely.
17:52:41 <RemiFedora> php54 in centos => extension in /opt/centos/...
17:52:49 <RemiFedora> so this is broekn and can't work
17:53:00 <Rathann> to be honest I'm not quite sure why time-api needs any approval from us
17:53:32 <abadger1999> RemiFedora: can't it work? it's just that slavek said, "no don't do that"?
17:53:46 <RemiFedora> yes, I know and I disagree with slavek
17:54:01 <abadger1999> RemiFedora: yeah, so I think I disagree with slavek too.
17:54:27 <abadger1999> its a use case we want to enable and this is the way to enable it.
17:55:25 <RemiFedora> simple fact. /opt/rh is own by scl-utils, and defined as %_scl_prefix by scl-utils => consistent
17:56:08 <RemiFedora> /opt/rh/foo/root is own by foo-runtime, and defined as %_root_prefix, byt defined by scl-utils => inconsistent
17:56:45 <geppetto> I think this is more of an exception … like we don't allow random packages to put things they want in /usr/include/python2.7 … but do allow it in /usr/lib/python2.7/site-packages etc.
17:57:10 <geppetto> And I think slavek is just thinking about the first case.
17:57:35 <RemiFedora> I mostly think slavek think "single vendor" (and don't care of other cases)
17:57:45 <geppetto> maybe
17:57:53 <limburgher> Back, if it still matters.
17:58:00 <abadger1999> RemiFedora: what about if there's /usr/scls/rht-ruby1.9.3 and /usr/scls/fdr-ruby1.9.3 ?  Does that work out fine with the macros?
17:58:13 <RemiFedora> the reason why I explain "Package cannot extends collection of other vendor."
17:58:48 <RemiFedora> and then we can find solution for another SCL (such as php54ext), for EPEL with its own tree
17:59:13 <abadger1999> RemiFedora: to be clear; you do want to extend collections of other vendors.  You're just pointing out how the potential rules slavek advanced will prevent that from happening, correct?
17:59:18 <RemiFedora> and then, have to play with symlink in %post scriplet to properly extend the php54 collection
17:59:29 * Rathann has to drop off, sorry
17:59:36 <abadger1999> Rathann: So long!
18:00:05 <RemiFedora> "you do want to extend collections of other vendors." => yes, I want to extent RHSCL (vendor=rh) in EPEL (vendor=fedora)
18:00:13 <abadger1999> Cool.
18:00:30 <RemiFedora> And i'm just trying to explain, that this is not possible.
18:01:09 <RemiFedora> else, show me how.
18:04:18 <RemiFedora> using,  /usr/scls/rht-ruby1.9.3 and /usr/scls/fdr-ruby1.9.3 will very probably don't work, I don't think "ruby" in 1 location will see the extension in the other
18:04:57 <RemiFedora> (and remember it will be /opt/rh/ruby193 and /usr/scls/fdr-ruby1.9.3)
18:05:38 <abadger1999> RemiFedora: you misunderstand
18:05:56 <RemiFedora> probably ;)
18:06:23 <abadger1999> If there's an extension to the ruby1.9.3 from redhat, it would build against the rht-ruby1.9.3 scl.
18:06:33 <abadger1999> and install into its subdirectory.
18:06:46 <abadger1999> But, doesn't that interact with the macros at a higher level?
18:07:03 <RemiFedora> no, the collection already exists. ruby193 in /opt/rh/ruby193 and I don't think this will change
18:08:12 <RemiFedora> so I try to explain that %_root_prefix = /opt/rh/ruby193 must be inherited from ruby193 not from scl-utils
18:09:33 <RemiFedora> but agin, it could be /opt/rh/ruby193 or /opt/centos/ruby193, so this have to be expanded at install time, not at buildtime
18:10:08 <RemiFedora> so, I really think this is broken because of the vendor part, so must of the SCL stuff are just unusable
18:10:42 <abadger1999> Re: inherit from rht-ruby1.9.3, yep, I agree.
18:10:48 <abadger1999> But that's the part that's broken, right?
18:10:54 <abadger1999> Not the vendor part specifically.
18:10:59 <RemiFedora> no, sorry, "all" is broken
18:11:27 <abadger1999> why?
18:11:52 <abadger1999> If root_prefix is set based on ruby1.9.3 instead of scl-utils, won't everything else work?
18:11:56 <RemiFedora> I think having package in EPEL that only work for a single vendor doesn't have any sensse
18:12:17 <abadger1999> RemiFedora: correct.  So i'm trying to figure out how to make it work with multiple vendors.
18:12:24 <RemiFedora> Yes if "root_prefix is set based on ruby1.9.3 " we'll be able to build extension
18:13:16 <RemiFedora> but we'll have to create  rh-ruby193-foo + centos-ruby193-foo + sl-ruby193-foo + oracle-ruby193-foo + etc
18:13:59 <RemiFedora> because extension build against rh-ruby182 will use "rh" path, so will only work on Red Hat
18:15:05 <RemiFedora> and our bulider only have RH repo... so ...
18:15:08 <abadger1999> RemiFedora: In terms of builds, yes.  But that's inevitable anyway.
18:15:51 <abadger1999> RemiFedora: I think what would be ideal is to be able to just change the value of foo in this line: %{?scl:%scl_package foo} and then it will build a binary general scl  that uses the correct paths.
18:16:06 <abadger1999> RemiFedora: do you agree?
18:16:30 <RemiFedora> not completly
18:17:24 <RemiFedora> if %_root_prefix is correctly inherited, it will build a binary, using the path of the main scl packeg
18:18:05 <RemiFedora> so usable against the "same" main scl package, from the same vendor
18:20:10 <abadger1999> <nod>
18:20:50 <RemiFedora> sorry, I'm very probably not clear... as it seems so simple for me (even if I have think to this problem for hours), so simple I can clearly explain it
18:22:51 <abadger1999> ah -- so I was waiting for a "But this  problem still occurs..." after that last sentence.
18:23:33 <RemiFedora> sorry, typo => "so simple I CAN'T clearly explain it"
18:23:49 <abadger1999> Is there no problem as long as _root_prefix is properly inherited?
18:24:04 <RemiFedora> there is less problem
18:25:39 <abadger1999> RemiFedora: k.  and to tell rpmbuild what to inherit from, we should just have to change %{?scl:%scl_package foo} to something else, right?
18:25:43 <abadger1999> hmm...
18:25:50 <abadger1999> what is foo in current scl packages?
18:25:58 <abadger1999> or..
18:26:01 <abadger1999> gah.
18:26:06 <abadger1999> I think I see part of the problem.
18:26:25 <abadger1999> But it's implementation of the current packages in redhat, not with scls themselves right?
18:27:14 <abadger1999> so foo is ruby1.9.3 in the redhat packages.  but that doesn't include any hint of what the vendor is.
18:27:18 <abadger1999> Is that right?
18:27:25 <RemiFedora> yes
18:27:50 <RemiFedora> I have sent another mail (I hope to be more clear)
18:28:03 <abadger1999> whereas what we really want is foo = rh-ruby1.9.3 ,  foo= fdr-ruby1.9.3, etc.
18:28:20 <abadger1999> that way vendor is part of the macros that can be changed inside the package.
18:28:35 <abadger1999> inside the general scl package.
18:28:52 <RemiFedora> hmm
18:30:29 <RemiFedora> %{?scl:%scl_package foo}  => foo is the name of the "mainstream" package (non-scl), mostly to define %pkg_name
18:30:54 <abadger1999> RemiFedora: huh.  then where do we define what scl this package belongs to?
18:31:08 <RemiFedora> nowhere ;)
18:31:16 <geppetto> ha
18:31:19 <abadger1999> oh that's where the -build package comes in isn't it?
18:31:26 <RemiFedora> in fact we must have foo-build in the buildroot
18:31:30 * abadger1999 holds head to keep it from exploding.
18:31:54 <RemiFedora> foo-build define %scl macro, used by scl-util for all the others macros
18:32:15 <abadger1999> also, *sigh* about how many macros we're defining to have the same calues.
18:35:46 <RemiFedora> sorry, I have to go for dinner (already stay too late... it's my child birthday...)
18:35:59 <RemiFedora> we'll try to continue by mail.
18:36:02 <abadger1999> RemiFedora: go go, family is more important than this :-)
18:36:11 <RemiFedora> bye and thanks
18:36:14 <abadger1999> RemiFedora: and it mean I can wrap u p the meeting too :-)
18:36:19 <abadger1999> #endmeeting