16:04:46 <abadger1999> #startmeeting fpc
16:04:46 <zodbot> Meeting started Thu Oct 31 16:04:46 2013 UTC.  The chair is abadger1999. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:04:46 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:04:51 <abadger1999> #topic Roll Call
16:05:00 * limburgher here
16:05:10 <abadger1999> #chair limburgher tibbs|w geppetto
16:05:10 <zodbot> Current chairs: abadger1999 geppetto limburgher tibbs|w
16:05:10 * geppetto is here
16:05:16 * RemiFedora here
16:05:23 <abadger1999> #chair RemiFedora
16:05:23 <zodbot> Current chairs: RemiFedora abadger1999 geppetto limburgher tibbs|w
16:05:49 <abadger1999> spot, SmootherFrOgZ: FPC ping, you guys around?
16:08:48 <abadger1999> alright -- let's get started with who we have.
16:08:59 <abadger1999> #topic SCLs -- Approval section
16:10:22 <RemiFedora> iirc we have 4 +1 last week ?
16:10:36 <abadger1999> ugh.
16:10:39 <geppetto> yeh, I think tibbs is the only person here who hasn't voted.
16:10:45 <abadger1999> Okay, I just saved the conflicts section
16:11:00 <limburgher> I was absent, did I vote in the ticket?  My memory's shot.
16:11:20 <geppetto> Oh, no then
16:11:33 <geppetto> Just mis-remembering you being here :)
16:11:51 <limburgher> geppetto:  I'm like Obi-Wan, I stick around. ;)
16:12:02 <limburgher> Can someone link the ticket and the bit I can vote on?
16:12:15 <RemiFedora> https://fedoraproject.org/wiki/User:Toshio/SCL_Guidelines_%28draft%29#SCL_Approval
16:12:16 <abadger1999> Changes from last week: Conflicts section updated.
16:12:33 <geppetto> https://fedorahosted.org/fpc/ticket/339
16:12:46 <geppetto> And, yeh, what RemiFedora said.
16:12:50 <abadger1999> Could still use some polishing but I think the basic premise there is what we all seemed to be working towards last week.
16:13:47 <abadger1999> SCL Retirement section added.
16:13:51 <RemiFedora> abadger1999, the conflicts section looks fine
16:13:56 <limburgher> So I should read from SCL Approval through to the end?
16:13:57 <tibbs|w> I'm reading over the changes.
16:14:35 <abadger1999> tibbs|w, limburgher: note, if you didn't read my draft after last week's meeting, the whole section is new (compared to bkabrda's draft).
16:15:02 <limburgher> abadger1999:  Ok.  Good thing I read quickly.
16:16:01 <abadger1999> The SCL Retirement section could maybe use some expansion and could definitely use some wording adjustment.  Some EPEL people brought up the issues with me this week.
16:16:34 <abadger1999> I think we should vote on the SCL_Approval section minus the SCL Retirement section.  Talk about the retirement section a little and then I can polish it up this week.
16:17:07 <abadger1999> There's also a few controversial things I'd like to ask -- if enough FPC members agree with them, I'll work on rewriting the rest of the draft with those in mind.
16:19:39 <limburgher> Ok, I think I'm mostly caught up.
16:19:56 <abadger1999> limburgher: anything that struck you as wanting discussion/want me to change?
16:20:04 <tibbs|w> Well, I'm kind of stuck.
16:20:59 <limburgher> abadger1999:  No, not really.  I keep vacillating between "SCLs are silly for Fedora" and "people want SCLs, let's do them the right way".  But that has little to do with the draft.
16:21:14 <tibbs|w> I guess the best I can say is that the section is about as good as I could hope for but I'm still not remotely positive about the whole SCL thing.
16:22:01 <abadger1999> <nod>  I understand the sentiments.
16:23:04 <tibbs|w> But in the interest of progress, I'll go ahead and +1 that section.
16:23:08 <abadger1999> Shall we vote then?
16:23:09 <abadger1999> Proposal: Approve the SCL Approval section minus the SCL Retirement section which will be voted on later.
16:23:12 <abadger1999> +1
16:23:14 <tibbs|w> +1
16:23:16 <geppetto> +1
16:23:18 <limburgher> +1
16:23:21 <RemiFedora> +1
16:23:46 <abadger1999> that's 5.
16:24:44 <abadger1999> #info SCL Approval section minus SCL Retirement section (will be voted on later) approved (+1:5, 0:0, -1:0)
16:25:00 <abadger1999> Does anyone have comments on the SCL Retirement section?
16:26:07 <abadger1999> Anyone want to say yes, the timing seems about right?
16:26:19 <abadger1999> :-)
16:26:28 <geppetto> is the 6 month security thing what we do for normal packages?
16:26:38 <limburgher> I think it needs technical clarification about how the scl will be removed, Obsoletes, or just not updated anymore and not in the next release?
16:26:44 <abadger1999> geppetto: We have no policies for normal packages.
16:26:54 <abadger1999> geppetto: It's currently escalate to fesco.
16:27:21 <limburgher> geppetto:  Or let it sit there and bitrot and be vulnerable.  That's not unpopular.
16:27:29 <limburgher> Sadly.
16:27:46 <geppetto> Ahh … so I'd be tempted to say something like: If it's been 2 weeks since a similar normal package got a security update, and the SCL still hasn't got one, then we'll automatically start looking at retiring it.
16:27:57 <limburgher> Rational.
16:28:06 <abadger1999> (fesco dealt with a similar issue yesterday -- maintainers who are active but do not deal with bugs entered into RH bugzilla.  fesco said, that's a violation of the package maintainer responsibilities policy.  If you point out such bugs, fesco will decide what to do.)
16:28:37 <abadger1999> geppetto: The one thing about that is that the packages are likely on different versions.
16:28:51 <abadger1999> The mainstream package may not be vulnerable at all.
16:29:11 <abadger1999> But I like 2 weeks instead of 6 months :-)
16:29:12 <geppetto> abadger1999: I'm kind of assuming that some active version of Fedora is likely going to have a similar version of the package.
16:29:36 <abadger1999> maybe a "whichever comes first" section?
16:29:36 <geppetto> That might not be true if SCL end up being used for really long term. back compat.
16:30:12 <abadger1999> 2 weeks since mainstream package fixes a vulnerability  or 6 months since security vulnerability was opened whichever comes first.
16:30:26 <geppetto> abadger1999: I guess, but one the one hand 6 months seems like a long time … and on the other it seems a little unfair to add responsibilities that normal packages don't have.
16:30:42 <abadger1999> we already do -- backwards compatibility.
16:30:54 <geppetto> Sure, I guess.
16:31:19 <geppetto> I'd be happy to add a "2 months without a security errata and we start looking at removal" as a general rule :)
16:31:35 <abadger1999> Okay.  I'd go for that too.
16:32:21 <geppetto> Ok, seems fine then :)
16:34:05 <abadger1999> Cool.
16:34:08 <RemiFedora> abadger1999, SCL Metapackage have an implicit dependency on -runtime. So I don't see any problem to add an explicit one.
16:34:37 <abadger1999> RemiFedora: k.  Question: why do we even have two separate packages?
16:35:01 <RemiFedora> as explained by slavek, you can install only a subset of the collection
16:35:19 <RemiFedora> the main package is just a metapackage which install most of the collection.
16:35:46 <geppetto> moar is better ;)
16:36:08 <RemiFedora> ex devtoolset-2  (in rhdts) is just a bug one, and most people will usually only install, for ex?  devtoolset-2-toolchain (gcc)
16:36:29 <abadger1999> hmmm....
16:36:31 <RemiFedora> s/bug/bug/
16:36:35 <RemiFedora> grr
16:36:36 <RemiFedora> bug
16:36:39 <RemiFedora> big
16:36:39 <geppetto> :)
16:36:45 <abadger1999> oh I see what slavek's writing... that's problematic.
16:37:10 * abadger1999 thinks about how to talk about this issue.
16:37:17 <geppetto> So … people will do: yum install scl-devtoolset-2 scl-devtoolset-2-toolchain … or just: yum install  scl-devtoolset-2-toolchain
16:37:46 <RemiFedora> just scl-devtoolset-2-toolchain
16:37:51 <RemiFedora> or scl-devtoolset-2-eclipse
16:38:06 <RemiFedora> or scl-devtoolset-2 (if they don't care of disk space)
16:38:07 <geppetto> So, after that main package "scl-devtoolset-2" won't be installed?
16:38:17 <RemiFedora> right
16:38:28 <abadger1999> alright -- so are we all clear that the term SCL is a collection of packages.  The SCL metapackage defines the basic package set that's being specified as a platform, and then there's general scl packages that both make up that platform and add features to it?
16:38:29 <geppetto> Ok … so the top level is like a group of all the packages in the SCL?
16:39:07 <RemiFedora> yes. a metapackage, empty, only deps
16:39:09 <abadger1999> here's where I'm seeing a problem -- people are going to want to add more general scl packages than the scl maintainers themselves envision maintaining.
16:39:35 <geppetto> My understanding before today was that the toplevel was the "minimal" group of packages … so if you did "yum install scl-devtoolset-2" there might still be some  scl-devtoolset-2-* packages not installed.
16:39:41 <abadger1999> Now that we have the bakwards compat section, I think we should let them do that .
16:40:22 <abadger1999> but the split between metapackage -runtime and metapackage main package doesn't seem to work with that.
16:41:28 <RemiFedora> geppetto, my understanding is a "common" group of packages. devtoolset-2 simply includes "all" the collection. When other collection only include a "minimal" set (ex php54)
16:41:41 <abadger1999> the metapackage main package can't keep track of all the general scl packages that other packagers might install.
16:41:49 <geppetto> wow … nothing like consistency
16:42:04 <abadger1999> s/install/create
16:42:25 <RemiFedora> right
16:42:44 <abadger1999> (also notes -- devtoolset would not be allowed by our SCL criteria... SCL maintainers would need to create separate SCLs with SCL dependencies for those things).
16:42:55 <limburgher> At some point the yum repo metadata will become self-aware, you do realize that, right?
16:43:09 * geppetto nods … going through the Approval process might well fix a bunch of these things.
16:43:43 <abadger1999> limburgher: it's a race between createrepo and yum-metadata-parser
16:44:07 <limburgher> abadger1999: :)
16:44:16 <geppetto> nah, dnf will win for sure.
16:44:36 <abadger1999> Okay -- this looks big.  Here's the issues I think we'll need to decide but we can think about them this week and decide next week:
16:45:12 <abadger1999> Are we going to stop packagers from adding other general scl packages than the SCL-meapackage owner envisioned to an SCL?
16:45:40 <RemiFedora> no
16:45:42 <abadger1999> If not, the number of SCL general packages will grow outside the control of the SCL-metapackage owner.
16:46:11 <abadger1999> What is the role of the main SCL metapackage vs the -runtime SCL metapackage in that situation?
16:46:51 <RemiFedora> runtime is like the filesystem package (should probably have be named <scl>-filesystem)
16:47:33 <abadger1999> RemiFedora: ah... so runtime does not depend on the main scl metapackage?
16:47:43 <RemiFedora> right
16:48:08 <abadger1999> and in fact, it should not depend on *any* other SCL packages?
16:48:17 <RemiFedora> every package depends on runtime.
16:48:28 <abadger1999> and it's a one-way street.
16:48:34 <RemiFedora> right.   (it only depends on scl-utils-runtime iirc)
16:49:07 <abadger1999> k
16:49:11 <abadger1999> alright, that makes sense.
16:49:22 <abadger1999> okay, let's move on.
16:49:23 <geppetto> Is there a sense of a user ever wanting to install just -runtime?
16:49:28 <RemiFedora> no
16:49:33 <geppetto> ok
16:49:55 <abadger1999> I have two and a followup controversial questions to let me continue working on the draft.
16:50:10 <RemiFedora> which one ?
16:50:19 <abadger1999> Filesystem location
16:50:20 <abadger1999> I don't see anything wrong with using /opt/$vendor/scl => We should just register a not-likely-already-used $vendor (fdr, fedoraproject, fedoraproject.org).
16:51:07 * limburgher grumbles quietly about /opt
16:51:09 <abadger1999> Can others live with that or do we insist on %{_libdir}/scl/$vendor or %{_prefix}/scl/$vendor instead ?
16:51:36 * RemiFedora thinks <vendor> will be a nightmare for third party repo, but dont see any other option (and is probably the only one to care about third party repo)
16:52:04 <limburgher> My preference is %{_prefix}/scl/$vendor
16:52:24 <abadger1999> limburgher: k.  Knowing that third party software will also be installed there?
16:52:25 <geppetto> My understanding was that they'd agreed to fix that
16:52:44 <geppetto> So for Fedora based SCLs it would use %_prefix
16:53:07 <geppetto> And third party SCLs could use /opt, and all the tools would work with both.
16:53:32 <limburgher> abadger1999:  Yes.
16:53:33 <abadger1999> geppetto: bkabrda said he'd look into doing it.. it would be hard to do it for two dirs,extremely hard to do it for $N dirs.
16:53:59 <geppetto> I'm sure the last thing I heard was that it would be easy for 2 dirs. and _maybe_ more difficult for more.
16:54:13 <abadger1999> limburgher: note --- I think %{_prefix}/scl is an FHS violation?
16:54:14 <RemiFedora> afaik, all magic rely on /etc/scl/prefixes/<sclname> which contains the root path of the SCL, so I don't see any issue have more than 1 dir
16:54:27 <limburgher> They could also fix it by staying out of /opt, easiest where N=1, but whatever.
16:56:30 <abadger1999> FHS: "Large software packages must not use a direct subdirectory under the /usr hierarchy."
16:57:43 <tibbs|w> That's ambiguous as to whether putting them in /usr/scl is a violation.
16:57:49 <abadger1999> limburgher: also: http://fedoraproject.org/wiki/Packaging:Guidelines#Filesystem_Layout  <= the pullbox there
16:58:08 <abadger1999> "Some interpretations of the FHS say that the FHS does not prevent distributions from creating and using directories outside of the listed hierarchies (for instance, adding new toplevel directories to / or adding new directories under /usr). For the purposes of the Fedora Packaging Guidelines, new directories of this sort are not allowed unless listed in the Guidelines. "
16:58:33 <limburgher> Ooh!  How about libexec?  /me ducks
16:58:47 <abadger1999> limburgher: yep -- libexec falls under that.
16:59:18 <abadger1999> So I guess - our precedent is, we try not to but we (FPC) can vote to include a new directory.
16:59:50 <limburgher> I just think it's safer to add to /usr than touch /opt at all.
17:00:26 <abadger1999> Hmm....  will this need to be multilib?
17:00:39 <abadger1999> I guess the internal multilib directories take care of those issues?
17:01:23 <abadger1999> for instance:  /usr/scl/fedora/scl-ruby1.9.3/usr/lib64/
17:02:01 <RemiFedora> missong the "root" part => /usr/scl/fedora/scl-ruby1.9.3/root/usr/lib64/
17:02:25 <geppetto> There's an explicit "root" dir. … why?
17:02:29 <abadger1999> Okay -- reverse question, then -- can everyone here live with %{_prefix}/scl as the root directory (and optionally [requires tooling change], third party vendors can use /opt)
17:02:39 <limburgher> YEs.
17:02:40 <geppetto> Yeh
17:02:43 <RemiFedora> geppetto, yes, there is, but don't know why
17:03:06 <abadger1999> alright -- so here's my followup: where do config and state files live?
17:03:11 <geppetto> boggle … whenever I heard "root" I thought they meant "/usr/scl/fedora/scl-ruby1.9.3" being the root of the SCL
17:03:19 <abadger1999> they can't live in %{_prefix}
17:03:32 <limburgher> Could we make an /etc/scl?
17:03:47 <geppetto> abadger1999: Has to be under /usr/scl/fedora/scl-ruby1.9.3/etc … or /usr/scl/fedora/scl-ruby1.9.3/root/etc (if the root thing is not a bug)
17:03:49 <abadger1999> do they just live in %{sysconfdir} and %{_statedir}  or do we make them live in /etc/scl and /var/scl?
17:03:49 <limburgher> with a <sclname> for each inside?
17:03:55 <RemiFedora> /etc/scl already exists (for scl-utils config)
17:04:01 <abadger1999> geppetto: they can't be there.
17:04:09 <geppetto> limburgher: AIUI they need all the files under a single tree.
17:04:15 <abadger1999> RemiFedora: right /etc/scl exists for a different purpose :-(
17:04:19 <geppetto> abadger1999: Why, FHS?
17:04:40 <abadger1999> geppetto: yeah.  and it's one of the hard requirements rather than a soft requirement.
17:04:56 <abadger1999> because %{_prefix} may be read-only and network shared.
17:05:01 <geppetto> I guess this is why /opt was chosen to start with then
17:05:11 <limburgher> abadger1999: That's the best reason
17:05:16 <geppetto> As they need their entire tree under a single root.
17:05:19 <abadger1999> geppetto: well -- /opt is also potentially read-only and network shared.
17:05:24 <abadger1999> I don't think they do
17:05:26 <limburgher> But /var isn't/ / /
17:05:27 <limburgher> . . .
17:05:35 <limburgher> Stupid fingers.
17:06:11 <abadger1999> In https://fedoraproject.org/wiki/User:Toshio/SCL_Guidelines_(draft)#SCL_Metapackage <= mmaslano has a comment about directories they're currently using outside of /opt
17:07:14 <RemiFedora> missing :   /usr/lib/systemd/system/*
17:07:20 <RemiFedora> (instead of init.d)
17:07:24 <abadger1999> there's no configuration for the package currently outside of /opt.  There is statedirs and log files our the package ouside of /opt
17:07:31 <abadger1999> RemiFedora: <nod>
17:07:39 <RemiFedora> missing /usr/lib/tmpfiles.d/
17:08:25 <geppetto> Yeh, there's nothing about naming of stuff anywhere either … like what are things in /etc/logrotate.d called?
17:08:26 <abadger1999> geppetto: also... fhs specifies that config files and state files for packages in /opt belong in /etc/opt/ and /var/opt/
17:09:01 <geppetto> abadger1999: fair enough
17:09:04 <RemiFedora> geppetto, /etc/logrotate.d/<packagename>  like usually ;)
17:09:29 <geppetto> RemiFedora: Right … so /etc/logrotate.d/scl-ruby-3.3-blah.conf ?
17:09:34 <RemiFedora> right
17:09:54 <geppetto> So … I guess we could say the same thing for stuff in /etc
17:10:36 <abadger1999> <nod> Yep -- /etc/mysql/ becomes /etc/scl-mysql5.0/
17:10:43 * geppetto nods
17:11:36 <abadger1999> I would rather use a directory for cleanliness, ease of review, and mirroring the scl root rid (%{_prefix}/scls).  but it would work from a technical standpoint.
17:11:53 <abadger1999> *scl root dir
17:13:18 <geppetto> having an extra dir. doesn't seem that appealing
17:13:35 <geppetto> Maybe it'd be easier to implement for packages though.
17:13:46 <geppetto> And might be better if people will want to install 666 SCLs.
17:14:18 <abadger1999> implement: yeah, some packages will hardcode in code the conf file name but allow setting the location via configure
17:14:20 <geppetto> But in what I'd hope is the common case of having < 10 SCLs installed, just having stuff prefixed scl- in /etc seems better at first thought.
17:14:28 <abadger1999> installing: yeah, that was what I was thinking of.
17:14:37 <geppetto> abadger1999: Yeh, that's the main thing I was thinking of
17:16:27 <abadger1999> there might also be some corner cases where a mainstream package's conf file already has a version number in it.
17:16:42 <geppetto> blah … ok, I could be convinced that just having a new root under each dir. is better … just due to the packaging implementation issues.
17:17:07 <RemiFedora> as the scl magick is changing value of %{_sysconfigdir}, a new dir seems required (like /etc/scls/ )
17:17:19 <geppetto> I assume we'd also need to say something about /var and /var/cache /var/spool etc. etc. ?
17:17:21 <abadger1999> okay.  I'll write up guidelines to match that.
17:18:00 <geppetto> it would also be nice if the "top level" dirs. could be named the same in /etc /usr /var etc.
17:18:13 <RemiFedora> so, to resume, we are going to ask to "explode" the single SCL tree, in the standard FHS tree ?
17:18:43 <geppetto> I guess.
17:18:56 <geppetto> Also it's not really super std. :)
17:19:13 <geppetto> But, yeh, looks like "no single root"
17:20:48 <RemiFedora> so /etc/scl, /usr/lib64/scl, /var/lib/scl, /usr/libexec/scl, /usr/share/scl, ...and so on ?
17:20:49 <abadger1999> RemiFedora: somewhat. at least, the main scl tree is for what would normally go in /usr, /etc/scls/SCLTREE is for conf files and /var/scls/SCLTREE is for state files.
17:21:09 <abadger1999> I'm thinking sysadmins would probably also appreciate it if log files were in
17:21:26 <abadger1999> /var/log/scls/SCLTREE  instead of /var/scls/SCLTREE
17:21:50 <abadger1999> RemiFedora: no to the dirs beginning with /usr/
17:21:57 <RemiFedora> ok, understood
17:22:06 <abadger1999> RemiFedora: All of those will be in /usr/scls/SCLTREE
17:22:36 <abadger1999> okay -- here's my other controversial sticking point:
17:22:39 <abadger1999> branches.
17:23:00 * abadger1999 pastes something slightly long
17:23:03 <abadger1999> releng issues aside, the goal is to have one package for all scl versions and one package for the mainstream version.  Inside of the mainstream version, there will be a branch for each fedora release (just like now).  Inside the scl version, there will be a branch for each scl+fedora version combination.  The master branch of the scl version will be a clone of the mainstream package master.  SCL macros will only occur in the scl git, not in
17:23:04 <abadger1999> the mainstream git.
17:23:24 <abadger1999> after looking at this for a while and the mingw precedent, that's my ideal.
17:23:46 <abadger1999> It's a bit of a deviation from how the scl team looks at it though.
17:24:41 <geppetto> ok
17:24:48 <geppetto> who does the scl team look at it?
17:24:51 <geppetto> s/who/how/
17:25:11 <abadger1999> they want to be able to have a single git repo for each package.  there would be scl+fedora version branches inside of there as well as the fedora version branches for mainstream versions.
17:25:24 <abadger1999> the mainstream packages can have scl macros.
17:26:19 <abadger1999> all macros are conditionalized so that they only apply when building an scl.
17:26:47 <abadger1999> tibbs|w: I think you also thought the approach I pasted above would be better?
17:27:45 <geppetto> Ahh, yeh
17:28:00 <abadger1999> In terms of how I rewrite the guidelines, if there are no scl macros in the mainstream package, then I can get rid of all the conditional logic.
17:28:02 <tibbs|w> Well, keeping the complication out of the main version is good.
17:28:17 <abadger1999> because the macros will only be present in the scl branches.
17:28:55 <geppetto> Probably … I can imagine that in some cases the advantage of having the same spec file would be greater than the advantage of having a clean main package.
17:29:02 <tibbs|w> Personally I don't understand why it isn't one separate package (from a pkgdb/git standpoint) per compat version.
17:29:27 <tibbs|w> But I'm still stuck in the "just make compat packages like we already do" mentality.
17:29:56 <limburgher> tibbs|w:  Why, because it works?
17:29:58 <limburgher> :)
17:30:13 <abadger1999> tibbs|w: atm, dgilmore thinks that we may need to do that for tooling reasons.  But the rationale for not doing that is that all the scl package spec files would largely be the same.
17:30:36 <tibbs|w> That assumes a whole lot about the software in question.
17:31:07 <abadger1999> because the %scl_name (I think that's the maro) is defined by the -build package, they think a lot of it would be boilerplate.
17:31:23 <geppetto> RemiFedora: FYI while most of the Fedora documentation is now out of date, it does explicitly say that the top level metapackage is supposed to be minimal: http://docs.fedoraproject.org/en-US/Fedora_Contributor_Documentation/1/html/Software_Collections_Guide/sect-Package_Layout.html
17:31:33 <tibbs|w> But it assumes that the build and install process of the individual versions is even remotely similar.
17:31:51 <tibbs|w> Which might not be the case, depending on the software.
17:31:53 <abadger1999> tibbs|w: true... but is there no more difference than if we had F20: foo-1.0 and F21: foo-2.0?
17:32:56 <tibbs|w> I guess I'm assuming that at some point you're trying to spare spec files between the different SCL versions.
17:33:13 <tibbs|w> I'm getting the impression I'm mistaken in that.
17:33:45 <tibbs|w> I've also caught another cold, so my brain isn't working.
17:34:25 <abadger1999> hmm... that's a good question.  The package implementing the main purpose of hte SCL probably has to be different because of versions (ruby-1.9.3 vs ruby-2.0, for instance).  but the packages that are in addition to that may work on both.
17:34:47 <abadger1999> I mean, the spec file may not need any changes.
17:35:05 <abadger1999> (But I definitely wouldn't wantto write guidelines that counted on that being the case).
17:35:24 <RemiFedora> right
17:36:00 <geppetto> yeh, the impression I get is what the SCL people want is that they can just build packages with SCLs enabled, or not.
17:36:11 <geppetto> And it all "just works"
17:36:12 <RemiFedora> yes
17:36:45 <geppetto> To which I'd probably reply, "optimism is a wonderful thing"
17:36:58 <abadger1999> :-)
17:38:23 <RemiFedora> geppetto, It just works (at least for my packages)
17:38:24 <geppetto> anyway … it's been over 1:35 now … do we want to try looking at any of the other tickets piling up?
17:38:39 <abadger1999> anyhow -- I just would like to know if fpc members would agree for me to go along the scl-macros-will-not-be-in-the-mainstream-package path or if they want me to preserve the conditionalize-all-the-things path.
17:39:22 <geppetto> RemiFedora: I can imagine it does, mostly, for simple packages … but I'm not sure how much packagers will be happy with it, and in general it seems like a form of "we are going to assume it does XYZ, but we haven't tested it"
17:40:07 <RemiFedora> yes, I agree, and by experience, it must be tested in scl and non-scl before saying "it will work"
17:40:31 <geppetto> abadger1999: I think we need to leave that stuff in … but make it obvious that just because you made an SCL of FOO you don't get to force the maintainer of FOO to have your SCL macros in his main specfile if he doesn't want them.
17:40:48 <geppetto> RemiFedora: yeh
17:41:11 <RemiFedora> geppetto, I agree
17:41:17 <limburgher> I'm about out of time.
17:41:45 <abadger1999> okay, so that's two for leaving conditionals in and two for simplifying.
17:41:56 <abadger1999> limburgher: got an opinion?
17:42:15 <RemiFedora> abadger1999, I'm for 'give maintainer the choice' ;)
17:42:47 <limburgher> abadger1999: Not a strong one either way.
17:43:03 <limburgher> If I had to choose, I'd lean towards simplifying.
17:43:18 <abadger1999> k.  I'll wait on doing anything with that then.
17:43:21 <geppetto> Yeh, I'm happy to say they should be separate if you want … but I'd rather if someone is maintaining httpd and scl-httpd-2.2 and they think it'll save them time to share the specfile that they can.
17:43:47 <geppetto> On the other hand abadger1999's idea of saying "no sharing" might be better if some proven packager needs to come in and do something.
17:44:04 <abadger1999> or a new maintainer comes along :-)
17:44:18 <geppetto> Yeh
17:44:38 <geppetto> So if you feel strongly about it … change it to say it has to be different and I won't complain :)
17:45:05 <abadger1999> mmm :-)  Okay :-)
17:45:18 <abadger1999> #topic https://fedorahosted.org/fpc/ticket/350  codimension-parser bundling exception.
17:45:28 <abadger1999> cmeng asks what the status of this is.
17:45:43 <abadger1999> There's 5 +1's so on the one hand this could be closed as accepted.
17:45:48 <abadger1999> But the other side is:
17:45:53 <geppetto> status * == backed up behind SCLs ;)
17:45:57 <abadger1999> what makes this different from rsync bundling zlib?
17:46:41 <abadger1999> If there's no difference, then I'd like to persuade people to either change their vote or write a new type of exception that allows this :-)
17:46:46 <abadger1999> Otherwise we're being unfair.
17:47:15 <geppetto> I think this was voted on the day I was away.
17:48:17 <geppetto> Hmmm, maybe not as I vaguely remember this.
17:48:39 <abadger1999> I'd have to look at the meeting logs to know who the 4 +1's in the meeting were.
17:48:42 <geppetto> maybe I just read the ticket
17:49:04 <geppetto> I did wonder … why didn't they just use fmemopen()
17:49:16 <geppetto> or open_memstream() whichever it is.
17:49:45 <geppetto> Why does rsync bundle zlib?
17:50:11 <geppetto> Oh, doesn't it need some weird API access to the data?
17:50:27 <abadger1999> geppetto: rsync had modified zlib to discard some data.
17:50:37 <geppetto> interesting
17:50:45 <abadger1999> so that they didn't have to send as much data over the wire in some cases.
17:51:06 <abadger1999> the changes didn't get back into upstream zlib for years.
17:51:15 <geppetto> I wonder what 0.000n% that was.
17:52:05 <abadger1999> because we had an open bug about it, eventually the rh rsync maintainer was able to push a patch to zlib upstream to add that api.
17:52:13 <geppetto> cool
17:52:33 <geppetto> So this woudl be different then given " I do not think that my changes could be accepted as an upstream feature."
17:52:38 <abadger1999> but we're talking years and years and much pulling of hair :-)
17:52:58 <abadger1999> geppetto: well... at some points in time, the rsync upstream said the same thing.
17:53:05 <geppetto> :)
17:53:48 <geppetto> I mean … given what I know, I'm tempted to -1 … but it already has 5 +1's … so as you said it's accepted.
17:53:58 <abadger1999> and looking at the codimension parser author's reply, I have to wonder why antlr collecting info in memory would be unacceptable to upstream.
17:54:12 <abadger1999> (unless you were one of the +1s previously :-)
17:54:31 <geppetto> I'm 95% sure I was on holiday during the cote.
17:54:36 <geppetto> s/cote/vote/
17:55:10 <geppetto> But in future when we leave tickets for an extra +1 or so … we should probably list who already voted ;)
17:57:06 <abadger1999> yeah.
17:57:23 <abadger1999> Maybe we should come back to this one another day.
17:57:40 <abadger1999> Does anyone have a quick and easy one they'd like to do?
17:58:08 <RemiFedora> 359 about init script ?
17:58:12 * abadger1999 will research who voted between meetings
17:58:22 <abadger1999> #topic https://fedorahosted.org/fpc/ticket/359
17:58:26 <geppetto> http://meetbot.fedoraproject.org/fedora-meeting-1/2013-10-10/fpc.2013-10-10-15.59.log.txt
17:58:46 <geppetto> So it looks like I did vote for it :-o
17:59:05 <geppetto> anyway...
17:59:34 <tibbs|w> Re 359, I'm happy to dump the foo-sysvinit packages now since we ship no other initsystems.
17:59:42 <abadger1999> -1
17:59:51 <abadger1999> We've voted on this issue numerous times.
18:00:07 <geppetto> yeh, I don't see the point in disallowing it when it harms nobody.
18:00:31 <RemiFedora> I think the question comes from a "new" package during its review
18:00:51 <RemiFedora> I can understand we can live with unuseful stuff in existing package
18:00:53 <geppetto> Right, but the wording already allows them to skip it if they want to
18:00:57 <abadger1999> I'd be okay with adding some sort of "nothing in fedora can use this at the moment" language.
18:01:06 <abadger1999> ie: emphasis that they can skip it.
18:01:12 <abadger1999> emphasize
18:01:15 <geppetto> Sure
18:01:23 <tibbs|w> I guess it would be nice to know just why someone thinks a -initscripts subpackage would be remotely useful.
18:01:29 <RemiFedora> I just found strange to submit a review with a -sysinit sub package
18:01:30 <abadger1999> <nod>
18:01:58 <tibbs|w> I forget what systemd will do when both a unit file and an initscript are installed.
18:02:17 <RemiFedora> tibbs|w, very strange things...
18:02:24 <tibbs|w> Because if installing the -sysvinit package changes behavior in any way, we really don't want them in the distro.
18:03:06 <abadger1999> tibbs|w: when we approved the guidelines, it would use the unit file.
18:03:09 <RemiFedora> tibbs|w, I have fix a bug recently, a package with a sysinit script with a "provides: http" in header
18:03:21 <abadger1999> I don't know if that's changed more recently, though.
18:03:31 <tibbs|w> And there could always have been bugs.
18:03:36 <abadger1999> <nod>
18:03:38 <RemiFedora> and systemd will use this init script when invoking "systemctl httpd.service"
18:04:04 <RemiFedora> so obviously, init script "can" breaks things
18:04:47 <RemiFedora> see https://bugzilla.redhat.com/show_bug.cgi?id=1012462
18:05:34 <tibbs|w> Hmm, confusing.
18:05:57 <tibbs|w> Well, remember when we pass guidelines that existing stuff is always grandfathered anyway.
18:06:13 <RemiFedora> yes
18:06:27 <tibbs|w> So if we change the guidelines, we're just doing it for new packages anyway.
18:06:35 <abadger1999> RemiFedora: is that a systemd bug or systemd feature?
18:06:46 <RemiFedora> probably a feature ;)
18:06:46 <tibbs|w> What's the difference?
18:07:02 <RemiFedora> but I think we shouold not alllow new package with sysinit script, so I'm +1 with the proposal
18:07:15 <abadger1999> bugs get fixed.
18:07:44 <limburgher> Hmm.  I could be +1
18:07:49 <tibbs|w> abadger1999: Objection, assumes facts not in evidence.
18:07:53 <geppetto> abadger1999: optimism is a wonderful thing ;)
18:08:24 <RemiFedora> systemd honours sysinit script, this is a feature.
18:08:40 <abadger1999> feature would make me say we need to adjust the guidelines to say something about not having both unit files and init scripts.
18:08:43 <geppetto> Blah … given that it could break things I guess I'm happy to +1 the proposal
18:08:44 <RemiFedora> sysinit having priority on unit file could be considered as a bug ;)
18:09:01 <abadger1999> RemiFedora: exactly :-)
18:09:21 * abadger1999 remains -1
18:09:50 <RemiFedora> abadger1999, what is the value of keeping sysinit scripts ?
18:09:59 <abadger1999> Maybe we should port all remaining sysv scripts to systemd and then ask that systemd grow an option to ignore sysv init scripts.
18:10:09 <RemiFedora> for the day we'll switch back to SysV  and drop systemd ?
18:10:32 <tibbs|w> One day something else will come along, I'm sure, but I doubt it will be old-style init.
18:11:29 <tibbs|w> My problem with these is that if you just do "yum install foo\*" you might just get different startup behavior than someone who did "yum install foo" and that's not entirely obvious or even discoverable.
18:12:33 <tibbs|w> And at this point I'm having a tough time understanding why any *-sysvinit packages currently exist.
18:12:44 <abadger1999> <nod>  But if it's a bug, then the bug should be fixed regardless.
18:12:56 <tibbs|w> It's not because of some recalcitrant maintainer who makes his own custom distro.
18:13:09 <tibbs|w> I think it's more people thinking it was a good idea for some reason.
18:13:30 <abadger1999> so sysadmin who did an install from source and used a sysvinit script and later upgraded to fedora package with systemd unit file doesn't end up i nthe same mess.
18:14:43 <tibbs|w> I don't know; we've not really considered that situation when evaluating other guidelines.
18:14:49 <RemiFedora> probably, but this is not our problem ;)
18:16:19 <abadger1999> <nod>  I'm talking about the bug, not the guidelines.
18:16:59 <abadger1999> Well, this won't pass today (but oculd in the ticket).  Anyone want to vote on this as a stop gap:  Proposal: add this to the page "As of Fedora 19 there are no init systems in Fedora that do not understand systemd unit files.  Creating sysvinit subpackages is unless you have a need for the subpackage yourself you should not be creating sysvinit subpackages."
18:17:15 <abadger1999> Err...
18:17:34 <abadger1999> Proposal: add this to the page "As of Fedora 19 there are no init systems in Fedora that do not understand systemd unit files.  Unless you have a need for the subpackage yourself you should not be creating sysvinit subpackages."
18:18:01 <geppetto> +1
18:18:06 <abadger1999> +1
18:19:10 <abadger1999> I'll also note in the ticket where voting on banning currently stands.
18:20:51 <abadger1999> RemiFedora, tibbs|w, limburgher: Want to vote on that?
18:23:29 <abadger1999> Okay, time to go home/back to work I guess :-)
18:23:39 * abadger1999 will update the ticket.
18:23:43 <abadger1999> #endmeeting