fedora-meeting-1
LOGS
16:09:02 <abadger1999> #startmeeting fpc
16:09:02 <zodbot> Meeting started Thu Oct 24 16:09:02 2013 UTC.  The chair is abadger1999. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:09:02 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:09:08 <abadger1999> #topic roll call
16:09:13 * geppetto is here
16:09:21 <abadger1999> #chair geppetto racor
16:09:21 <zodbot> Current chairs: abadger1999 geppetto racor
16:09:26 <Rathann> here
16:09:46 * RemiFedora is here
16:09:56 <abadger1999> #chair Rathann, RemiFedora
16:09:56 <zodbot> Current chairs: Rathann RemiFedora abadger1999 geppetto racor
16:10:09 <abadger1999> spot said he'd be absent from this one.
16:10:21 <Rathann> I've just seen him speak in -devel
16:10:27 <abadger1999> tibbs, SmootherFrOgZ: You around for FPC meeting ?
16:10:29 <abadger1999> Hmm
16:10:31 * spot is only here for five minutes or so
16:10:36 <Rathann> ah
16:10:48 <abadger1999> spot: quick, +1 all the things ;-)
16:10:52 <geppetto> Ok, Marcela said she might be a few mins. late, so if we could start with a simple non-SCL one that'd be nice.
16:10:54 <spot> lol.
16:11:05 <mmaslano> geppetto: I'm here
16:11:20 <abadger1999> Okay, we have five here.
16:11:30 <geppetto> mmaslano: Ahh, different nicks confusing me :)
16:11:53 <mmaslano> geppetto: really? :)
16:12:05 <geppetto> I'm easily confused :-o
16:12:08 <abadger1999> Which will be enough to pass things if we all agree.
16:12:13 <abadger1999> #topic SCLs
16:12:54 <abadger1999> I've started modifying bkarbrda's draft: https://fedoraproject.org/wiki/User:Toshio/SCL_Guidelines_(draft)
16:13:43 <abadger1999> Definitions section, I changed SCL Package to General SCL Package... SCL Package was too confusing to read later in the document.... gets confused with "SCL" too easily.
16:14:06 <mmaslano> abadger1999: which means we are doing it twice :) he told me he has changed all your comments in his draft
16:14:06 <abadger1999> SCL Approval I added from our discussions from the past few weeks.
16:14:12 <abadger1999> Hmm..
16:14:17 <abadger1999> at what time?
16:14:29 <abadger1999> mmaslano: I synced after last week's meeting I think.
16:14:30 <mmaslano> don't know
16:14:49 <abadger1999> He had said on the mailing list that he addressed my comments a week prior to that.
16:14:53 <abadger1999> mmaslano: I can check history.
16:14:59 <mmaslano> abadger1999: nevermind
16:15:01 <geppetto> The Bkabrda draft still has /opt in the example.
16:15:58 <abadger1999> 20th sept as last bkarbrda update.  I forked on Oct 16.
16:16:03 <abadger1999> So I think we're okay there.
16:16:17 <mmaslano> ok
16:16:29 <RemiFedora> yes
16:17:33 <abadger1999> I think we could look at this section: https://fedoraproject.org/wiki/User:Toshio/SCL_Guidelines_(draft)#SCL_Approval
16:17:48 <abadger1999> Fix up my few remaining questions and vote on it (or ask me to add things to it)
16:18:43 <abadger1999> naming is a small bit dependnt on whether to use /opt or not... so it might be good to vote on the three proposals I've heard (and written onto that page) then I can proceed to update the rest of hte draft based on that.
16:19:43 <abadger1999> The rest of the SCL Metapackage section nad the General SCL Package section needs more work.
16:20:13 <geppetto> For just the SCL approval bit, I can't see anything that I object too.
16:20:16 <abadger1999> Mostly just better wording, hcanging order, making sure that things are all explained.
16:20:38 <abadger1999> #topic SCL Approval section https://fedoraproject.org/wiki/User:Toshio/SCL_Guidelines_(draft)#SCL_Approval
16:20:49 <geppetto> yeh, most of the page seems fine … a few niggle bits, but given the approval process it's not the end of the world even.
16:20:51 <geppetto> +1
16:21:31 <abadger1999> I'm +1 to the Approval section.
16:21:45 <abadger1999> I am willing to add more criteria if people tell me what they want added.
16:21:50 <RemiFedora> +1 for approval
16:22:04 <abadger1999> In the guideline, All the admon/questoin boxes would be removed.
16:22:23 <geppetto> Well atm. everyone still has to go through us … so it's not the end of the world if we don't have a tight set of rules to start.
16:22:28 <abadger1999> <nod>
16:23:54 <RemiFedora> About "There can be only one" I think it's again the idea of SCL. A SCL whould allow to use a specific version accross various distro (fedora/rhel) and version.
16:24:18 <RemiFedora> so at  one time we can have the same version in mainstream + scl
16:24:44 <abadger1999> RemiFedora: Okay, so just the part that I highlighted in the Question box?
16:24:45 <RemiFedora> and already in the note
16:24:49 <RemiFedora> yes
16:24:59 <geppetto> RemiFedora: As I read that it's "only one, _per. version_" … so you could have 1 SCL version of py2.7, 1 SCL version of py2.4 and one SCL version of py3.x
16:25:22 <abadger1999> Yeah, I'd be willing to relax that as related to the mainstream packages.
16:25:45 <geppetto> we just want to cut down on people want to ship N slightly different versions of rails or openstack or something.
16:25:47 <abadger1999> So you could have mainstream python-22.7 package + scl-py2.7.  You just couldn't have scl-py2.7.1 and scl-py2.7.2
16:25:49 <RemiFedora> geppetto, I agree, single SCL for a given version
16:26:02 <abadger1999> typo: mainstream python-2.7
16:26:02 <geppetto> right
16:26:42 <Rathann> Approval section looks ok to me, +1
16:27:42 <abadger1999> https://fedoraproject.org/wiki/User:Toshio/SCL_Guidelines_(draft)#There_can_be_only_one <= updated
16:28:58 <RemiFedora> abadger1999, I confirm, apache ABI/API is stable accross minor version (httpd-mmm macro)
16:29:19 <RemiFedora> so you ex is good :)
16:29:31 <abadger1999> RemiFedora: Thanks.  /me takes out the admon/question there.
16:31:40 <geppetto> racor: you got any questions?
16:35:12 <RemiFedora> abadger1999, Conflicts with non-SCLs and other SCLs => I think you can have another type of conflict
16:35:49 <RemiFedora> ex, if you have php53 + php54 + php55, with mod_php (for system apache) in each collection. You can only have 1 mod_php enabled at the same time
16:36:45 <geppetto> that's more alternatives and conflicts though, right?
16:36:52 <geppetto> s/and/than/
16:36:54 <RemiFedora> and I think we can encounter other case, of SCL extending another app.
16:37:14 <RemiFedora> geppetto, yes, exactly, this are alternative
16:37:49 <RemiFedora> you can install various, but only use 1 (as for network port conflicts)
16:37:59 * abadger1999 added a few sentences about inter-scl dependencies and compat to the first paragraph of: https://fedoraproject.org/wiki/User:Toshio/SCL_Guidelines_(draft)#Compatiblity_Guarantees
16:38:06 * abadger1999 thinks about the mod_php case
16:38:54 <abadger1999> One option would be that each php scl would have an httpd package.
16:39:04 <RemiFedora> => "... used via a config file."
16:39:15 <abadger1999> scl-php5.3-httpd, scl-php5.4-httpd, scl-php5.5-httpd
16:39:45 <abadger1999> then you'd treat the mod_php question as the user starts the httpd that came with that scl.
16:39:59 <RemiFedora> including httpd is php collectio seems bad idea, against "size" criteria.
16:40:23 <abadger1999> RemiFedora: well... so that's a currently unaddressed area.
16:40:37 <RemiFedora> and against " SCLs must not target more than one main package/stack"
16:40:37 <abadger1999> The Approval and Size section is talking about approval of the SCL.
16:40:44 <geppetto> Yeh, that seems pretty bad … unless you have a big stack of something that includes php and httpd … having them both in one collection seems bad.
16:40:46 <abadger1999> It doesn't talk about approval of packages inside of an SCL.
16:40:47 <geppetto> but, meh.
16:41:50 <RemiFedora> but, for me the config file is the right way.
16:42:00 <abadger1999> I'm on the fence about that.... If I am not the scl-ruby1.9.3 maintainer but I really want to have scl-ruby1.9.3-my-db-bindings, should I be able to build a general scl package for fedora that has that?
16:42:15 <abadger1999> it doesn't affect the compat guarantees so I lean towards "yes'.
16:42:19 <RemiFedora> perhaps with an additional requirement in priority on mainstream package (when possible)
16:43:25 * abadger1999 trying to think of other ways to do this and still continue in the same spirit.
16:43:46 <abadger1999> So the problem with an alternatives based approach is that you can't run both mod_php's at the same time.
16:43:57 <abadger1999> Whereas the port conflicts, you can -- just not out of the box.
16:44:21 <Rathann> it's possible to run different httpd+mod_php versions on different ports
16:44:36 <RemiFedora> yes
16:44:36 <Rathann> so no reason to ban that
16:45:01 * RemiFedora agree
16:45:02 <abadger1999> Rathann: yeah -- so that's what my thought on a different httpd was striving for... but maybe there's a way to use system httpd but with a different config file or something?
16:45:11 <geppetto> yeh, I'd like of it like MTAs
16:45:32 <geppetto> you can run two at once … but for most people while they might want to install both, they only want to run one.
16:45:43 <geppetto> but I guess I could be convinced otherwise :)
16:46:57 <RemiFedora> well... I run 1 apache with 3 php backend (5.3,5.4,5.5) but I probably a bit crazy ;)
16:46:58 <abadger1999> So.. what files would need to be present so that the user could easily choose to start up a httpd with mod_php5.4 and a separate httpd with mod_php5.5 after tweaking a config setting?
16:47:35 <RemiFedora> abadger1999, best solution is to not use mod_php
16:47:39 <abadger1999> a separate systemd unit file and a separate /etc/httpd/conf.d?
16:47:44 <RemiFedora> abadger1999, yes
16:47:57 <Rathann> yes
16:48:40 <abadger1999> RemiFedora: k.  So are you saying we should ban mod_php and similar situations from SCLs?
16:48:53 <RemiFedora> no
16:49:12 <RemiFedora> single php version => mod_php is the simplest.
16:49:26 <RemiFedora> vrious php version => php-fpm is greater
16:49:48 <Rathann> you mean better ;)
16:49:57 <RemiFedora> and as said by geppeto, must with use only one
16:50:09 <RemiFedora> s/must/most/
16:50:13 <RemiFedora> Rathann, yes
16:51:49 <RemiFedora> so to resume, I think we shoud only prohibit file conflicts.
16:52:28 <RemiFedora> port / extension will be treated as alternatives, single version working out of the box, multiple version will require some configuration
16:52:40 * abadger1999 isn't realy comfortable with that.
16:52:56 <geppetto> abadger1999: which bit?
16:53:24 <abadger1999> so if all we're prohibiting is file conflicts, it takes away the value add of SCLs.
16:53:42 <RemiFedora> ?
16:54:36 <abadger1999> ie: right now, I can package a parallel postgresql server that has no file conflicts.  I just can't run both the mainstream and parallel postgresql server in parallel out of the box.
16:54:50 <RemiFedora> yes
16:55:14 <abadger1999> so what does packaging one of those as an SCL add to the equation?
16:55:38 <RemiFedora> you can install both
16:55:42 <abadger1999> I suppose there's no out of the box difference, though, so.. hmmm...
16:55:52 <abadger1999> RemiFedora: you can install both if packaged parallel as well.
16:55:53 <RemiFedora> and can run both (after changing the configured port)
16:56:48 <RemiFedora> abadger1999, yes, that's is exactly the confusion, I think
16:57:22 <abadger1999> RemiFedora: getting onto a different question... how do tyou configure apache to know where to load the SCL's mod_php from?
16:57:32 <RemiFedora> yes we know how to create parallel packages of nearly anything; SCL is just a common and simple framework/tool to do it
16:58:20 <RemiFedora> the SCL's mod_php drop a file in the /etc/httpd/config.modules.d
16:58:28 <RemiFedora> s/drop/put/
16:59:19 <abadger1999> RemiFedora: with a full path to the module instead of a relative path?
17:00:01 <abadger1999> RemiFedora: and it would have to be commented out -- user would have to uncomment the one that belonged to the mod_php version that they wanted to run?
17:00:08 <RemiFedora> hmm... need to check... don't remember if apache support full path
17:01:03 <RemiFedora> currently the SCL mod_php also create a libphp5x.so in the module dir (a link to the scl dir)
17:02:06 <RemiFedora> apache will only load the first one (and emit a warning for the second one)
17:02:37 <RemiFedora> so user have to comment the mod_version php they dont want to run ;)
17:03:02 <RemiFedora> (or unnistall the package)
17:03:19 <abadger1999> I think we should make them uncomment the one they want.
17:03:45 <geppetto> so all SCL mod_* would come non-working?
17:03:46 <abadger1999> That is more in line with things like "systemd managed services are installed disabled by default"
17:03:52 <RemiFedora> it's another solution, but it will not work out of the box
17:04:37 <abadger1999> it would help with the problem of user installs something and suddenly something else stops working.
17:04:39 <abadger1999> actually..
17:05:07 <RemiFedora> the reason why I say previously "priority on mainstream package"
17:05:37 <RemiFedora> why, for php example, means, you can install as many mod_php you want, the mainstream will be used
17:05:58 <RemiFedora> (until disabled or uninstall)
17:06:35 <abadger1999> okay that brings me back to the other aspect of this -- if we think about wanting to run applications that need a specific version (which is provided by an scl), then we're back  in the boat of user has squirrelmail installed.  User installs sugarcrm and because that uses a different php, it breaks squirrelmail.
17:06:41 <RemiFedora> but of course this is the solution used for now, still discussable
17:07:40 <langdon> could we enable the "right" mod_php in scl enable actiom?
17:08:15 <RemiFedora> langdon, no
17:08:23 * Rathann has to go away and take care of a work-related emergency
17:09:00 <RemiFedora> mod_php is dl_open by apache (which is not aware of scl)
17:09:10 <abadger1999> langdon: It might be possible but it doesn't address the basic problems of "user has to pick which mod to load" and "one application's mod version requirement may conflict with another application's mod version"
17:09:41 <RemiFedora> abadger1999, I think such conflicts can't be avoid.
17:09:57 <abadger1999> RemiFedora: modifying apache startup script to run scl enable mod_phpX.Y :-)
17:10:06 <langdon> abadger1999: well.. it sorta does, if i choose to enable scl_x then i assume scl_x_mod_php is the one that gets usd.. however httpd needs to get restarted or something..
17:10:24 <RemiFedora> if an app requires php < 5.4 and another php > 5.5 ... both can't run together...
17:10:56 <langdon> RemiFedora: not in the same httpd (most of the time).. but on diff ports, with diff httpd instances they could be
17:10:58 <abadger1999> langdon: right -- but that's you, the user, choosing.  It's not the system figuring out what's right by itself.  And it doesn't address the problem of two apps needing different versions.
17:11:04 <RemiFedora> langdon, remember, first thing "service" command do is => clean the user environment ;)
17:11:49 <langdon> RemiFedora: oh.. i see hwat you are getting at ..
17:12:28 <langdon> i think it is fine to expect the "app runner" to mod the service command to use the right "enablement"
17:12:40 <abadger1999> Rathann: Bye!
17:14:08 <RemiFedora> abadger1999, and about you ex. I think mainstream app should  use mainstream php version
17:14:32 <RemiFedora> if an app need a scl version, it should be package as an scl
17:14:58 <abadger1999> RemiFedora: Sure.  but you still can't run the two apps together even if one ofthem is in an scl, right?
17:15:39 <RemiFedora> you can if you configure correctly apache to use 1 version for some app and another for other app.
17:16:08 <abadger1999> RemiFedora: okay... let's put it this way, even if one app is in an scl, installing that app's scl can still break the already installed app?
17:16:22 <RemiFedora> remember that if foo requies php < x and bar requires php > x, we cannot package them with current single version ;)
17:16:22 <mmaslano> abadger1999: was the first paragraph approved? I'm lost
17:16:40 <geppetto> mmaslano: It got +4
17:17:16 <geppetto> mmaslano: and two didn't vote … spot had probably left, racor hasn't spoken since the start so maybe he got pulled away too
17:17:31 <mmaslano> so, should I work on it more or FPC doesn't have quorum today?
17:18:04 <abadger1999> mmaslano: s/paragraph/section/  ;; it's at +4;; but we're now discussing one of those subsections and we don't seemto agree yet on what it should say.
17:18:08 <RemiFedora> mmaslano, yes you don't have quorum anymore
17:18:09 <geppetto> mmaslano: So it's likely it will be approved, but it needs one more +1 and seems unlikely to get it today (or presumably anything else) … so, yeh, no quorum.
17:18:30 <abadger1999> mmaslano: well -- we're still working on writing somethng we can agree on.
17:18:52 <abadger1999> but if you're interest is whether we'll be able to finalize a vote on something today, the answer is we won't be able to.
17:18:52 <mmaslano> abadger1999: I guess went to deep into specifics of apache and his modules
17:19:24 <abadger1999> mmaslano: Well -- it speaks to a basic problem with the conflicts portion.
17:19:28 <RemiFedora> well... was an example... but yes...
17:19:41 <abadger1999> this will affect other things than apache.
17:19:45 <mmaslano> RemiFedora: I thought apache could load more modules if there were some upstream changes. I heard something about it long time ago...
17:20:15 <RemiFedora> yes, ex apache could load libphp4 and libphp5
17:20:38 <langdon> i really think apache is just an example... you may have this with anything that an scl depends on / connnects too..
17:20:45 <RemiFedora> but not 5.4 and 5.5 (which are both libphp5)
17:21:00 <RemiFedora> trying to resume
17:21:26 <RemiFedora> curently single version, so we can run anything which need an older or more recent version
17:21:46 <RemiFedora> with SCL we can run various version, but this can create some conflicts
17:22:09 <RemiFedora> not perfect, but we have a better situation than without scl (I think)à
17:22:50 <RemiFedora> sorry "curently single version, so we CAN'T run anything which need an older or more recent version"
17:23:11 <abadger1999> For isntance, this would also affect something that needed a specific version of postgresql since the port would need to be configured in the application.
17:23:54 <RemiFedora> I think server address + port is always configurable ?
17:24:13 <abadger1999> RemiFedora: the problem is breaking already installed apps.
17:26:22 <geppetto> I think postgres is much easier
17:26:23 <RemiFedora> so, conflicts are conflicts and we have to deny them
17:26:36 <geppetto> As generally the only "user" in that instance would be the apps. in the SCL
17:26:39 <abadger1999> RemiFedora: or relax the conflicts guidelines for some set of cases.
17:26:50 <geppetto> whereas the webserver will often need to be accessed directly.
17:27:04 <abadger1999> it's tough to say that, though as the user should be able to work around the conflicts if they try hard enough.
17:27:22 <geppetto> yeh, I think allowing SCL to conflict with each other a lot would be bad.
17:27:56 <geppetto> I'd much rather have them either installed "off" by default (so user needs to comment the module in), or say they need to bundle Eg. httpd and can't use the system one.
17:28:01 <abadger1999> (pretty simple to configure postgres and all apps that need that version to use the right port.  Harder to setup new systemd unit files and parallel httpd config for the other application... and may need to put a proxy in front of that if you want everything to appear to come from port 80)
17:28:03 <geppetto> Not sure how viable the later is though.
17:31:45 <abadger1999> alright -- so I think this is a summary so far:  We have +4 to the majority of the approval section.
17:31:55 <abadger1999> The conflicts subsection is currently problematic.
17:32:13 <abadger1999> We definitely need to come up with something that acknowledges the problem.
17:32:53 <abadger1999> We can "solve" it by punting the issue to the user or trying to make something more complx to address it.
17:33:52 <abadger1999> Allowing conflicts to prevent installing both seems like a bad idea as the user should be able to fix these with a greater or lesser amount of manual intervention in most cases.
17:35:29 <geppetto> yeh
17:35:51 <geppetto> ofc. it might not come up that often in practice, so there's that.
17:37:15 <abadger1999> yeah.  although -- mod_wsgi linked against python2 and mod_wsgi linked against python3 is probably going to hit us in a few years time.
17:37:53 <geppetto> maybe
17:38:01 <abadger1999> Okay, there's only three of us left but we're all okay with the Compatibility Guarantees section?
17:38:05 <geppetto> but it might turn out that very few people want both installed.
17:38:34 <geppetto> yeh, most of it seemed pretty obvious to me.
17:39:17 <geppetto> It might be worth saying that you can make a change from a lesser to a _bigger_ guarantee, within a release.
17:39:28 <geppetto> Or was there a reason you said that wasn't allowed?
17:39:28 <abadger1999> makes sense.
17:42:53 <abadger1999> okay, updated: https://fedoraproject.org/wiki/User:Toshio/SCL_Guidelines_(draft)#Changing_a_Guarantee
17:44:13 <abadger1999> Alright I'll work on something for the Conflicts section and hopefully next week we can approve the SCL Approval section.
17:44:14 <geppetto> looks good
17:44:28 <geppetto> ok, cool
17:44:54 <abadger1999> I'd like to try to vote on some controversial things that are tying up the other portions of the guidelines from being finalized next week too... at least filesystem location.
17:45:26 <geppetto> one can hope :)
17:46:00 <abadger1999> #action abadger1999 to keep plugging away at the draft -- goal for next week is to approve the SCL Approval section.
17:47:21 <abadger1999> RemiFedora: Question in a different part of hte draft: "SCL metapackages must not be noarch. The filesystem directories contained in the metapackage may contain arch-specific paths." <= bkarbrda had: "If all the packages in SCL are noarch, then the metapackage may be noarch, too."
17:47:27 <abadger1999> RemiFedora: was my change correct?
17:48:06 * abadger1999 thinks it is because end users might add arch-specific packages on top of the packages we provide for the scl.
17:48:26 <abadger1999> so they'll need the arch-specific directory layout.
17:48:43 <RemiFedora> abadger1999, at first time there was a bug, which is fixed now (very recently)
17:49:06 <RemiFedora> so "If all the packages in SCL are noarch, then the metapackage may be noarch, too." (but this is very corner case, I don't know of any noarch scl)
17:50:05 <abadger1999> Hmm...and what about end users adding general scl packages to the SCL on their systems?
17:50:40 <abadger1999> wouldn't that mean that we'd never be able to know if an SCL contains only noarch packages b/c the end user can do anything they want?
17:52:33 <geppetto> What do you mean "users adding general scl packages to the SCL on their system" ?
17:53:30 <abadger1999> We provide scl-ruby1.9.3.  User adds scl-ruby1.9.3-oracledbdriver to that on their system.
17:53:44 <geppetto> how can they do that?
17:53:53 <abadger1999> create a package.
17:54:15 <geppetto> but just because the prefix matches doesn't change scl-ruby1.9.3
17:54:28 <geppetto> or am I missing something
17:54:37 <abadger1999> nothing would prevent them from  doing a mock build just like we're telling fedora packagers they can do in the Building Packages section. right?
17:55:09 <abadger1999> geppetto: The packge ends up inside of /opt/fedoraproject/scls/scl-ruby1.9.3/
17:55:16 <geppetto> so … they generate their own new scl-ruby1.9.3 from scratch? … which happens to include -oracledbdriver?
17:55:27 <geppetto> abadger1999: Oh, I see what you mean.
17:55:36 <abadger1999> scl-ruby1.9.3 is just a single metapackage.
17:55:55 <geppetto> Meh. … I'm happy to say the top level can't be noarch, as I doubt anything will qualify anyway (and it's just a metapackage)
17:56:06 <abadger1999> then we add one or more packages to that (for instance, scl-ruby1.9.3-ruby and scl-ruby1.9.3-rubygem).
17:56:12 <abadger1999> yeah.
17:56:33 * abadger1999 marks that question as answered
17:58:02 <RemiFedora> I agree on "top level can't be noarch"
17:58:14 <RemiFedora> (even if technically possible)
17:59:07 <abadger1999> Okay, we're closing in on two hours so time close the meeting.
17:59:27 <geppetto> sounds like a plan
17:59:31 <abadger1999> #endmeeting