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