16:05:03 <geppetto> #startmeeting fpc
16:05:03 <zodbot> Meeting started Thu Aug 27 16:05:03 2015 UTC.  The chair is geppetto. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:05:03 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:05:03 <geppetto> #meetingname fpc
16:05:03 <geppetto> #topic Roll Call
16:05:03 <zodbot> The meeting name has been set to 'fpc'
16:05:26 <tomspur> IIRC all packages where maintained separately in different packages: https://admin.fedoraproject.org/pkgdb/package/python26-greenlet/
16:05:31 <geppetto> #chair tibbs
16:05:31 <zodbot> Current chairs: geppetto tibbs
16:05:32 <gholms> Magical container unicorn dust
16:05:33 <geppetto> #chair tomspur
16:05:33 <zodbot> Current chairs: geppetto tibbs tomspur
16:05:35 <geppetto> #chair orionp
16:05:35 <zodbot> Current chairs: geppetto orionp tibbs tomspur
16:05:37 <geppetto> #chair mbooth
16:05:37 <zodbot> Current chairs: geppetto mbooth orionp tibbs tomspur
16:05:43 <gholms> (Oh, sorry)
16:05:59 <tibbs|w> I'm starting to think we should just macroize the entire %package definition.
16:06:00 <mstuchli> tomspur: Maybe I'm missunderstading, but isn't that what the draft is arguing for then?
16:06:20 <geppetto> tibbs: The best part of that is I'm really _not sure_ if you are trolling or serious :)
16:06:24 <tibbs|w> Howdy folks.  Ememergencies happening all at once.
16:06:48 <tomspur> mstuchli: Doesn't the draft try to have everything in the normal (fedora) spec?
16:06:56 <tibbs|w> geppetto: Yeah, I know; the idea is distasteful to me but it might be something to try.
16:07:00 <orionp> Yes, rpm needs to grow template instantiation
16:07:25 <geppetto> Yeh, I mean … right after the specfile language is completely rewritten :-o
16:07:28 <tibbs|w> Anyway, I think that ticket is too recent for the meeting agenda so maybe we can push it to open floor.
16:07:35 <mstuchli> tomspur: Oh yeah, right :) In EPEL spec, but yeah
16:07:59 <gholms> Conary did both of those, and look where it went.  ;)
16:08:38 <mstuchli> tibbs|w: That's fine with me
16:08:47 <geppetto> gholms: Probably a lot of factors there, and specfile language was but a very tiny part of it
16:08:53 <geppetto> #topic Schedule
16:08:55 <geppetto> https://lists.fedoraproject.org/pipermail/packaging/2015-August/010946.html
16:09:14 <gholms> geppetto: Indeed.  I do miss inheritance.
16:09:16 <tomspur> mstuchli: I read the draft like that you add each new python3X to the e.g. python-greenlet.spec and merge the branches back and forth between Fedora and EPEL. If this is really just in the EPEL spec, maybe putting it into the EPEL guidelines is enough as tibbs suggested
16:09:48 <mstuchli> tomspur: Sure, that does seem sensible. But FPC still has to approve those, correct?
16:10:21 <geppetto> #topic #565 	New python package guidelines create upgrade path problem from old guidelines
16:10:21 <geppetto> .fpc 565
16:10:21 <geppetto> https://fedorahosted.org/fpc/ticket/565
16:10:22 <zodbot> geppetto: #565 (new python package guidelines create upgrade path problem from old guidelines) – fpc - https://fedorahosted.org/fpc/ticket/565
16:10:32 <geppetto> While we are all in the mood for python stuff, might as well look at this one
16:10:58 <tomspur> mstuchli: I don't know :)
16:11:06 <Rathann> hi
16:11:21 <geppetto> Did we really intend for everyone to rename all their packages?
16:11:26 <mbooth> geppetto: Speak for yourself, "in the mood for python stuff" indeed :-)
16:11:26 <geppetto> #chair Rathann
16:11:26 <zodbot> Current chairs: Rathann geppetto mbooth orionp tibbs tomspur
16:11:57 <tibbs|w> My python mood hasn't changed from "why does it have to be so terrible" in several years....
16:11:59 * geppetto thinks it's much more likely we wanted new py2 compat. packages to be named py2-
16:12:32 <geppetto> tibbs: because everything is terrible, so it fits in that way :)
16:14:30 <tomspur> I thought renaming makes it easier to switch the default python later on, but seems to have forgotten about the obsoletes...
16:15:01 <geppetto> yeh, if we want to rename we need obsoletes
16:15:10 <tomspur> Would adding the obsoletes to the py2 macro and then moving it to the py3 macro solve it?
16:15:12 <geppetto> Or yum/dnf is going to ignore it
16:15:37 <tibbs|w> tomspur: You should never need to move it to the py3 macro.
16:15:41 <geppetto> Yeh, it should be fine … also AIUI py3 isn't going to be /usr/bin/python for a long time
16:15:51 <tibbs|w> Put it in the py2 macro.  Keep it there for 18 months or so.
16:15:54 <geppetto> maybe ever?
16:15:54 <orionp> Ideally you obsolete the last packaged version
16:15:57 <tibbs|w> Then drop it.
16:16:20 <orionp> but I suppose you could just keep bumping the version
16:16:21 <tibbs|w> That's enough time to cover anyone who might upgrade.
16:16:25 <geppetto> tibbs: it's probably worth keeping it a bit longer
16:16:31 <tomspur> tibbs|w: what if the python3-foo package is the default and should provide python-foo? So it should also have the obsoletes, doesn't it?
16:16:34 <tibbs|w> geppetto: Our usual rule is two releases.
16:16:35 <geppetto> tibbs: just in case someone skips a couple of releases
16:16:55 <tibbs|w> tomspur: By that time there should be no dependencies on python-* at all.
16:17:02 <geppetto> tibbs: Yeh, but, with something that's going to rename a lot of packages … it's nice to give it a bit longer
16:17:24 <tibbs|w> Whatever works.  As long as it goes a couple of releases before /usr/bin/python switches over.
16:17:30 * geppetto nods
16:17:42 <mbooth> Correct usage of obsoletes/provides is documented here: https://fedoraproject.org/wiki/Packaging:Guidelines#Renaming.2FReplacing_Existing_Packages
16:17:52 <geppetto> indeed
16:19:02 <tomspur> Adding it to the macro would "gratuitously pollute the version space upwards"
16:19:21 <tomspur> As the macro doesn't know the $obsEVR, but only $provEVR
16:19:39 <orionp> right - although it may not matter in practice
16:19:53 <tibbs|w> Right, though you could accept it as an optional argument.
16:20:32 <tibbs|w> I'd just like to avoid making additional mess, but adding the line when you convert the package and removing it later isn't that much of a big deal.
16:20:39 <tibbs|w> My concern is that people won't remove it later.
16:20:45 <geppetto> Yeh, in practise using the prov. version is probably fine
16:21:29 <geppetto> But I'm happier with either of the other solutions
16:21:33 <tomspur> Why is the version polluting a problem?
16:21:45 <mbooth> tibbs|w: Does it matter if it emitted with macro? Macro can drop it a couple of released and mass rebuild gets rid of it in use
16:22:03 <tibbs|w> mbooth: Right, having the macro do it gets it done for free.
16:22:13 <tomspur> mbooth: Actually, I understood it like this in the first place...
16:23:37 <orionp> For random packages the version space thing matters  more - for this instance where it's just python-/python2-/python3-(name) I don't see a big issue
16:24:05 <orionp> no one is going to go back and package python-foo < current version
16:24:39 <orionp> We're also going to emit spurious obsoletes for new python package for a bit, but meh
16:25:01 <mbooth> orionp: Probably also does not in practice
16:25:07 <mbooth> does not matter
16:26:34 <orionp> So: http://ur1.ca/nkqfb ?
16:26:59 <geppetto> +1
16:27:11 <tibbs|w> +1 assuming it actually works.
16:27:17 <mbooth> Don't you need provides too to make upgrades work?
16:27:32 <geppetto> the provides are just above it, no?
16:27:34 <tibbs|w> mbooth: It's there already.
16:27:41 <tibbs|w> The diff just doesn't show it.
16:27:52 <mbooth> Ahh, nvm -- -not enough context
16:27:53 * tomspur is unsure if a "\n" is missing. +1 otherwise
16:27:58 <orionp> mbooth - not really, it just maintains package name compatibility
16:28:01 <tibbs|w> Are these macros still in the main python package?
16:28:06 * tomspur nods
16:29:00 <orionp> hmm, yeah, probably need a \n
16:29:23 <orionp> Previously just inherited from the line in the spec?
16:29:56 <Rathann> does it handle epochs?
16:30:01 <tomspur> Yes
16:30:26 <tomspur> vr = rpm.expand("%{?epoch:%{epoch}:}%{version}-%{release}")
16:30:37 <orionp> Full modified macros: http://ur1.ca/nkqhh
16:32:41 <tomspur> So python-foo obsoletes python-foo? It should go a few lines above to the python2- case
16:32:58 <tibbs|w> I suggest folks run through some test cases.
16:33:16 <geppetto> +1
16:33:46 <geppetto> But, yeh, now it looks to me like it should be in the first if case, and not the last one
16:34:58 <orionp> ah, oops
16:39:56 <orionp> With tomspur's fix substr fix http://ur1.ca/nkqla
16:41:16 <tomspur> +1
16:42:07 <tibbs|w> What are we at?
16:42:14 <mbooth> +1, looks good to me
16:42:19 <orionp> +1
16:42:32 <geppetto> +1
16:42:33 <Rathann> +1 as well
16:43:38 <geppetto> isn't there 6 of us?
16:44:02 <geppetto> Ahh, tibbs didn't vote yet
16:44:27 <tibbs|w> I thought I did back there a bit, but +1
16:45:34 <geppetto> #action Automatically add obsoletes for < provides version, in python_provides macro. (+1:6, 0:0, -1:0)
16:46:01 <geppetto> Ok, now just bundling things :-o
16:46:03 <geppetto> #topic #560 	Bundling exception for rubygem{molinillo,thor,net-http-persistent}
16:46:04 <geppetto> .fpc 560
16:46:04 <geppetto> https://fedorahosted.org/fpc/ticket/560
16:46:05 <zodbot> geppetto: #560 (Bundling exception for rubygem{molinillo,thor,net-http-persistent}) – fpc - https://fedorahosted.org/fpc/ticket/560
16:48:59 <orionp> Imagine, a package named bundler is bundling..
16:49:24 <geppetto> indeed
16:49:37 <geppetto> The words "They love bundling"
16:49:38 <tomspur> About 1: Can the bundled molinillo then installed/used so that always the bundled one is the system one? Sounds like that should be possible from  link [2]
16:50:15 <geppetto> tomspur: that's the fourth question, AIUI … in that they changed the namespace
16:50:40 <geppetto> tomspur: it's not obvious to me that they didn't just add a bunch of stuff to the begining, which would make using a system one possible
16:51:15 <tomspur> I see
16:52:05 * mstuchli has to leave, but if you would be so kind as to say how you think the Python 3 in EPEL guidelines could be improved during the open floor I'll be sure to read it in the logs tomorrow.
16:53:57 <geppetto> I'm not sure about 560 … it seems like a bad situation for the fedora packagers, maybe at some future time we can solve this by having a giant ball of mud repo. and stop caring about upstreams that dont' care back.
16:54:00 * geppetto sighs
16:55:04 <tibbs|w> I don't really know enough about the situation to say one way or the other.
16:55:38 <orionp> Does anything use rubygem-bundler in Fedora?  Perhaps just not packaging it....
16:56:07 <tibbs|w> I guess end users might want to use it to bundle.
16:56:25 <orionp> Then they can gem install bundler...
16:56:28 <geppetto> I don't think we can drop rubygems though, right?:)
16:56:35 <orionp> No, that we can't
16:57:10 <mbooth> I appreciate that the maintainer tried unbundling first -- this is nice change to see :-)
16:57:19 <tibbs|w> Indeed.
16:57:36 <tibbs|w> Why not package the two libraries separately?
16:57:38 <geppetto> Yeh, vondruch is pretty experienced
16:57:44 <tibbs|w> Or is that really much different from just bundling them?
16:58:22 <geppetto> You mean have N versions of molinillo?
16:58:48 <tibbs|w> Well, at least one of the libraries is the same as upstream with a different namespace.
16:59:12 <tibbs|w> So, package both.  We've done it before.
16:59:17 <geppetto> Yeh, I think so.
16:59:30 <tibbs|w> But I don't know if it's worth the effort.
16:59:55 <tibbs|w> I need to update the policy to make sure that before things even get to us, they add the Provides: bundled(whatever) tags.
17:02:05 <tibbs|w> Anyway, I still don't know what to do here.
17:02:46 <tibbs|w> There is some justification in terms of reducing the dependency tree of core packages, but I'm not sure how much weight to give that argument.
17:03:13 <orionp> No, that we can'tBundler and Rubygems can't have dynamically resolved dependencies.
17:03:23 <tibbs|w> Can't parse that.
17:03:26 <orionp> Sorry,
17:03:40 <orionp> Upstream states: Bundler and Rubygems can't have dynamically resolved dependencies.
17:04:13 <orionp> Which I can kind of parse, at least in the rubygems case
17:04:23 <orionp> it's the base for pulling in other stuff
17:04:55 <tibbs|w> Well, in their case maybe, but not in the distro case.
17:04:57 <orionp> I'm leaning towards +1 for rubygems, but just wondering if we should just from bundler
17:05:09 <geppetto> yeh, that's like saying rpm can't have dynamic deps.
17:05:11 <orionp> sorry, just drop bundler
17:06:08 <tibbs|w> If that were actually true of RPM, you could just statically link it.
17:06:27 <orionp> But aren't they is more of a self-hosting situation?
17:06:27 <tibbs|w> But RPM isn't going to go and have its own modified copy of lua or glibc.
17:07:10 <tibbs|w> orionp: I'm saying that might be justified in their case, but not ours.  And it's still no excuse for them to just go modifying the things they bundle just for the hell of it.
17:07:20 <tibbs|w> Again, software engineering.  Do they speak it?
17:09:03 <geppetto> I'm going to guess: no
17:09:06 <tibbs|w> Anyway, we can rant about how dumb upstream is, but that doesn't change their overall dumbness.
17:09:26 <geppetto> yeh
17:09:46 <geppetto> As orionp said, I guess we just shrug and accept rumbygem stupidity … and drop bundler
17:09:55 <tibbs|w> So what do we do?  Will upstream continue to just pull in anything they might ever want to call when they add features?
17:10:05 <geppetto> thor … I don't know
17:10:19 <geppetto> anyone know how important that is?
17:10:41 <tibbs|w> My guess is that it provides the command line interface.
17:11:01 <tibbs|w> Maybe sort of like bundling argparse?
17:11:19 <geppetto> hmm … nevermind, the last two are bundled in bundler
17:11:37 <geppetto> so if we drop bundler the only real mess we have is molinillo bundled in rubygems
17:12:32 <geppetto> So I guess I'm +1 on that
17:14:02 <tomspur> +1 from me too for bundling in rubygems
17:14:06 <orionp> too bad vondruch doesn't appear to be on IRC at the moment
17:14:34 <tibbs|w> I kind of wonder why milinillo is actually a separate project.
17:15:13 <tibbs|w> But yeah, I can accept bundling that molln* thing.
17:15:18 <tibbs|w> Can't type it for some reason.
17:15:32 <mbooth> I guess I don't know why they wouldn't want to use rubygems's resolver no matter what it is -- if rubygems is new enough to use milinillo, then that's a bonus bonus
17:15:49 <mbooth> But I do not speak ruby
17:15:56 <tibbs|w> And they don't speak software engineering.
17:16:03 <tibbs|w> So I guess you're even.
17:16:15 <mbooth> Touché
17:16:18 <tibbs|w> Anyway, +1 for rubygems.
17:16:24 <mbooth> Same, +1
17:16:27 <tibbs|w> But I just don't know about bundler.
17:16:38 <mbooth> Is it really a leaf package in Fedora?
17:17:01 <geppetto> Can someone do a quick --what-requires?
17:17:12 <tibbs|w> It goes back to the question of whether we want to provide a complete development environment, or enough of an environment that people can bring up a complete development environment.
17:17:21 <orionp> # repoquery --whatrequires rubygem-bundler
17:17:22 <orionp> rOCCI-server-tests-0:1.0.5-3.fc21.noarch
17:17:24 <orionp> rubygem-appraisal-0:0.5.2-2.fc21.noarch
17:17:25 <orionp> rubygem-bundler-doc-0:1.7.3-1.fc21.noarch
17:17:27 <orionp> rubygem-bundler-doc-0:1.7.6-1.fc21.noarch
17:17:29 <orionp> rubygem-bundler_ext-0:0.3.1-2.fc21.noarch
17:17:35 <orionp> rubygem-gemnasium-parser-0:0.1.9-3.fc21.noarch
17:17:35 <orionp> rubygem-rails-1:4.1.5-1.fc21.noarch
17:17:35 <orionp> vagrant-0:1.7.2-9.fc21.1.noarch
17:17:35 <orionp> I keep forgetting that dnf repoquery sucks
17:17:48 <orionp> rails
17:17:50 <orionp> nice
17:17:50 * geppetto sighs … rails!
17:17:54 <mbooth> Heh
17:18:02 <tibbs|w> vagrant would be kind of a problem.
17:18:11 <geppetto> yeh
17:18:26 <tibbs|w> I can't understand why anything would want to call bundler, though.
17:18:32 <geppetto> I wonder if we can undepend those two packages?
17:19:50 <tibbs|w> I guess bump back to vondruch and ask.
17:19:58 <geppetto> yeh
17:20:16 <tibbs|w> I keep wanting to call him vondutch.
17:20:19 <geppetto> We ae at +4 for rubygems
17:20:35 <geppetto> orionp: Rathann: Want to vote for rubygems?
17:21:02 <orionp> I'm +1 for rubygems
17:21:34 <Rathann> ouch, upstream is pretty hostile
17:21:42 <orionp> Although it's looking like dropping bundler is going to drop a lot
17:21:43 <Rathann> however vondruch didn't mention one thing
17:22:04 <Rathann> that we as distro make sure that this "Bundler and Rails may need need to load different versions of Thor." doesn't happen
17:22:23 <Rathann> which seems to be their main point against unbundling
17:23:03 <Rathann> I'm speaking of https://github.com/bundler/bundler/issues/3647
17:24:59 <orionp> If I hear "only guaranteed to work with version X" one more time....
17:26:07 <geppetto> Yeh, pretty soon they'll only "allow" certain versions of libc or certain kernels?
17:26:09 * geppetto sighs
17:26:26 <geppetto> just bundle everything!
17:26:28 <orionp> Well it seems upstream doesn't want bundler packaged, so there
17:26:46 <geppetto> seems good to me :)
17:26:59 <orionp> The Bundler team does not provide support for installing or using Bundler as an OS package
17:27:16 <tibbs|w> Well then we shouldn't be packaging it.
17:27:17 <orionp> I'm happy to oblide
17:27:20 <orionp> oblige
17:27:50 <geppetto> Rathann: You want to vote on the rubygems bit?
17:28:46 <Rathann> I'm -1
17:28:55 <geppetto> #action Allow rubygems to bundle molinillo, because software engineering is hard (+1:5, 0:0, -1:1)
17:30:02 <mbooth> It's been 90 minutes, I will have to leave
17:30:17 <tibbs|w> Yeah, I wish bundling discussions didn't have to take so long.
17:30:23 <geppetto> #info Everyone seems to be leaning on just dropping "Bundler", upstream doesn't seem to want anyone to ship it and presumably rumbygems can get the mess if devs. want it. The deps. on it from vagrant and rails seem bad though … can they be removed?
17:30:57 <orionp> Sounds good
17:31:10 <tibbs|w> I agree.
17:31:26 <geppetto> Ok, do we want to skip 562 and 564 until next week then?
17:31:34 <geppetto> Both are bundling requests :)
17:32:25 <orionp> Yay
17:32:28 * tomspur nods :)
17:32:37 <geppetto> #topic Open Floor
17:33:00 <geppetto> Ok, anything super important bring up now … or I'm going to close and eat some pizza :)
17:33:20 <tomspur> Could we talk about the python3 on epel situation?
17:33:36 <orionp> I'm up for some
17:33:46 <tomspur> Can those guidelines directly be added to the EPEL guidelines or do we need to vote it?
17:33:55 <geppetto> Sure, although I'd heavily lean towards it not being a set of macros. so you can build on N versions of py3 at once
17:34:11 <Rathann> sorry, I'm felling quite a bit under the weather so I'll be dropping off now
17:34:20 <geppetto> But that if people want new versions they have to do some new versioned packages, and/or SCL/containers/whatever
17:34:30 <Rathann> take care and bye
17:34:31 <geppetto> Rathann: Ok, thanks for coming and get better
17:34:49 <tibbs|w> tomspur: We don't control the EPEL stuff.
17:34:57 <geppetto> Red Hat should take care of maintaining old versions of py3 … that's what they do.
17:35:12 <tibbs|w> BUt at this point they don't maintain any py3.
17:35:27 <tibbs|w> My concerns about EPEL stuff is that it always gets into Fedora packages.
17:35:28 <geppetto> There isn't a verison of py3 in el7?
17:35:34 <tibbs|w> geppetto: There is.
17:35:43 <tibbs|w> Well, there's one in EPEL.
17:35:46 <tibbs|w> There isn't in RHEL.
17:35:59 <geppetto> really? … interesting … I assumed we shipped one.
17:36:10 <tibbs|w> It was a big deal that it made it into EPEL.
17:36:11 <geppetto> I guess that makes it messie
17:36:35 <geppetto> I'm not sure what we do then
17:36:44 * tomspur doesn't get it why the python3_pkgversion needs to be macronized
17:36:56 <geppetto> My guess is we'll have to break the ABI constraints on py3
17:37:31 <tomspur> How about requiring the package name to be python3-foo on https://fedoraproject.org/wiki/User:Bkabrda/EPEL7_Python3 and shipping it on epel only? Then it wouldn't touch Fedora packages
17:37:50 <orionp> tomspur - to handle switching the python3 version automatically
17:37:57 <tomspur> uh
17:38:46 <tibbs|w> but... Fedora doesn't care about witching the python3 version automatically.
17:38:58 <tibbs|w> As in, that kind of just happens.
17:39:00 <orionp> Right, but epel does
17:39:00 <tomspur> It already needs to be named python3-foo. Says the text
17:40:16 <geppetto> Yeh, it's just that they expect to also have python35- in the future
17:40:21 <geppetto> which … blah
17:40:35 <tibbs|w> This is crazy.
17:40:42 <geppetto> As I said, I think we just shrug and say there are going to be a lot of ABI breaks for py3 in EPEL7
17:40:48 <orionp> crazy,  like a fox!
17:41:30 <orionp> It states:
17:41:30 <geppetto> Everything is terrible, much like always.
17:41:31 <orionp> If a python3-<name> Fedora repo exists, it must be used. If a python-<name> SRPM exists in base RHEL, python3-<name> must be created and used (see #Explanation).
17:41:32 <orionp> Otherwise if python-<name> Fedora repo exists, it must be used.
17:41:46 <tibbs|w> If it can all be hidden in some reasonable macros then fine.  If it's just going in EPEL and not going to bother Fedora packages then fine.  But otherwise, I don't understand why we spent so much time trying to get the python guidelines cleaned up.
17:44:21 <orionp> The EPEL draft needs to get completely rewritten in light of the Fedora changes
17:44:36 <geppetto> Yeh, I doubt it's going to be some reasonable macros … and nobody will want to completely change their packages as they migrate from Fedora to EPEL
17:44:51 <geppetto> That kind of defeats the point of EPEL too
17:44:53 <tibbs|w> orionp: Maybe that's what made it look so bad to me.
17:45:51 <tibbs|w> geppetto: Except that if EPEL is going to have such a big piece of policy thhat Fedora isn't ever going to need, then there's not really any way to keep one spec.
17:46:05 <tibbs|w> And I've really been trying to find a way to eliminate the differences, too.
17:46:09 <geppetto> yeh
17:46:15 <geppetto> My opinion is that shouldn't happen
17:46:30 <geppetto> If they want to do that, I can see the desire … but it isn't EPEL
17:46:34 <tibbs|w> Sorry, what's "that"?
17:46:52 <geppetto> They shouldn't have a huge difference in policy for EPEL vs. Fedora
17:47:04 <tibbs|w> Yes.
17:47:11 <tibbs|w> But I do understand their predicament.
17:48:19 <tibbs|w> But really, if they put 3.4 in EPEL (which they did) and commit to never breaking compatibility then.... What choice do they have?
17:48:35 <tibbs|w> Someone's going to get to maintain that code forever.
17:48:47 <geppetto> I don't think they can make that commitment … or that people should believe them if they do
17:49:02 <tibbs|w> My personal opinion is that the packages in the distro (or EPEL) shoud work with each other.
17:49:19 <tibbs|w> They don't have to package a python34 stack forever.  If someone needs it for their application, they can build it.
17:49:26 <geppetto> sure
17:49:52 <tibbs|w> If the distro needs python3 and everything _in_ the distro works with python35 then python3 should just be 35 and that's the only version.
17:49:58 <orionp> We are not committing to supporting 34 forever
17:50:02 <orionp> in epel
17:50:10 <tibbs|w> Then what's the point of all of this?
17:50:24 <orionp> So people can use python3 in epel
17:51:01 <orionp> The version of python3 will change over time
17:51:19 <tibbs|w> So exactly why won't the current Fedora guidelines work?
17:51:22 <tibbs|w> The macros are all there.
17:51:49 <tibbs|w> Last I checked packages built and worked just as they do in Fedora.
17:51:53 <orionp> Because at time we will be building two python3X packages, and the packages are called python3X-
17:52:10 <tibbs|w> And that's not "so people can use python3 in EPEL".
17:52:19 <tibbs|w> People can use python3 in EPEL just fine.
17:52:24 <tibbs|w> This is for something else.
17:52:38 <orionp> what's it for then?
17:52:56 <tibbs|w> I guess supporting multiple simultaneous python3 stacks.
17:53:21 <tibbs|w> Which is  what all of this disagreement has been about.
17:53:23 <orionp> Right, which is pretty much required if you are going to have python3 in epel
17:53:38 <tibbs|w> And that requirement is what we're not understanding.
17:53:59 <tibbs|w> You only need one for distro consistency.
17:54:19 <orionp> Handling the transition from python3.X to python 3.X+1 with some grace
17:54:21 <tibbs|w> If you want the old one to support things end users can do, they can just build it.
17:54:43 <orionp> that's true of everything we package
17:55:01 <tibbs|w> I'm just not seeing it.  And certainly not seeing the need to contaminate Fedora packages with a bunch more crap.
17:55:15 <geppetto> I mean … the transition will be happening in Fedora, right?
17:55:38 <orionp> geppetto - no in epel
17:55:50 <geppetto> But it will also ba happening in Fedora
17:55:52 <tibbs|w> The point is that Fedora somehow will handle this.
17:56:07 <tibbs|w> If EPEL can't handle this and needs all of this extra policy and work then something's wrong.
17:56:10 <geppetto> So EPEL can wait for Fedora to do each minor version transition, and then take the result
17:56:26 <tibbs|w> Anyway, like I said, if a Fedora branch of a package never sees any of this then I'm fine.
17:56:42 <tomspur> Fedora handles it from release to release. How do you want to update python34 to python35 in epel?
17:56:50 <tibbs|w> I don't even think we need to care if that's the case.
17:57:06 <orionp> Fedora won't define with_python3_other so the extra packages won't be built in Fedora
17:57:13 <geppetto> tomspur: Import a bunch of new packages like a Fedora release upgrade
17:57:30 <geppetto> Well, bunch of new packages upgrades
17:57:31 <tibbs|w> But the stuff will actually get into the spec files.
17:58:02 <tibbs|w> If it gets into Fedora spec files then FPC does need to address it.
17:58:23 <tibbs|w> I just don't see why people love these complicated specs.
17:58:51 <geppetto> Anyway … it's been another 30 mins.
17:59:10 <geppetto> Maybe we can have them upgrade the policy vs. the latest Fedora policy
17:59:13 <orionp> Perhaps this helps https://lists.fedoraproject.org/pipermail/epel-devel/2015-February/010902.html
17:59:20 <tibbs|w> Maybe I'm just pissed because I probably wouldn't have wasted any of my time trying to clean things up had I known this was coming.
17:59:23 <geppetto> See if that looks more acceptable (My guess is no, but it can't hurt)
17:59:46 <orionp> And yes, I can work on an updated sample spec
18:01:49 <geppetto> But I think you'd be much better off doing stuff in coprs/Fedora until you are happy with it … and then just updating python3 and all related packages in EPEL (which only ever has one version).
18:02:28 <geppetto> If users want to stay on 34 for a bit, they can just not upgrade to the new python3 package.
18:03:03 <geppetto> But it's possible I could be persuaded
18:04:07 <geppetto> Anyway … anything else anyone wants to bring up?
18:04:21 <tibbs|w> Just a note that file triggers are going to be nice.
18:04:29 <tibbs|w> Assuming they work the way we want them to work.
18:04:30 <geppetto> Yeh, hopefully :)
18:05:17 <geppetto> dropping the number of things needed in %post has been on a bunch of people's wishlist for a long time :)
18:05:45 <tibbs|w> I think most packages that have %post will have no %post after this.
18:05:53 <geppetto> Yeh, hopefully :)
18:06:14 <orionp> Once RHEL7 is retired....
18:06:38 <geppetto> that's … not soon :)
18:07:07 <orionp> maybe my son will one day see the time when..... :)
18:07:13 <geppetto> ha
18:07:38 <tibbs|w> No ldconfig, no systemd scriptlets
18:07:46 <tibbs|w> Anyway, I have to run....
18:08:20 <orionp> me too, getting hungry....
18:08:37 * geppetto nods
18:08:46 <geppetto> Ok, see you next week
18:08:52 <geppetto> #endmeeting