On Tue, Jan 18, 2011 at 08:51:26PM +0100, Antoine Pitrou wrote: > On Mon, 17 Jan 2011 09:21:56 +0100 > Michael scherer <m...@zarb.org> wrote: > > > > There is also the issue on bytecompilation ( > > https://qa.mandriva.com/show_bug.cgi?id=50484 ). > > I have exposed there the various problem, and apart from explaining > > that the solution I chosed was not better than the other, no one gave a > > compeling > > argument into one or the others alternatives. > > That depends how "compelling" you expect the argument to be :) > The current situation is clearly not satisfactory.
I agree that the solution is not perfect for everybody, and if I had one that would not be without problem, I would have adopted it. > The solution of generating bytecode at install time looks fine. I am > not an RPM specialist though, but if you have non-RPM specific questions > feel free to ask them, I'd be glad to answer. Well, that's not satisfying from a rpm pov, unfortunately. But with some patchs, that the one that I would use, yes. until that, i prefer know documented breakage, than new undocumented breakage. (ie, shadok proverb, if you want to have less unhappy people, just hit always the same ). > > Finally, a vast part of the policy is handling 2to3, a topic that we didn't > > discuss > > at all, and I would not be confortable to adopt it without first looking at > > it and > > discussing it. > > What is the issue with "handling 2to3"? It's a developer tool and > certainly shouldn't be invoked at install time if that's what you are > asking. Generally, I don't think you (as a packager) have to invoke > 2to3 manually at all. If 2to3 is part of the packaged software's build > process, then their setup.py will probably invoke it automatically with > the right options. I as more speaking of the transition from pyton 2 to python 3. I think the easiest on a policy point of view is to handle this like 2 separate languages, but that mean twice the work. And so we should at least try to do better ( not sure that we can, of course ). -- Michael Scherer > Regards > > Antoine. > >