On Wed, Jan 19, 2011 at 02:07:18AM +0100, Antoine Pitrou wrote: > On Wed, 19 Jan 2011 00:55:40 +0100 > Michael scherer <m...@zarb.org> wrote: > > > > > 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. > > Can you explain why it isn't? I'm sure other packages generate stuff at > install-time, right? Also, the list of files is well-known (it's > everything named "*.py" that goes somewhere inside /usr/lib/pythonXXX/).
Because that would 1) requires a patch to rpm that we do not have or 2) patch all python packages to had %ghost on all *.pyc, and do a compilation of *pyc ( the 2nd part is easy, the first one is slightly harder to automate ) 3) do not care about file tracking, but that's unclean. Do not get me wrong, I think that's the way forward, but that's not applicable in a few days. And I cannot think of a rpm generating stuff at install time that do not requires specific intervention in the spec. Usually, we have packages that register themself in a dynamic list ( man, info, .desktop ), or that trigger symlink ( updates-alternatives ) , and those symlink are not tracked by rpm, and that's a suboptimal solution ( ie, you cannot do a research by file name, etc ) > > > 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 ). > > Handling them as two separate languages looks indeed like the right > thing to do, IMO. In any case, as I said, you shouldn't be the one > wondering about 2to3. Upstream developers do, if that's the conversion > method they chose for their project. Well, I was not clear, when i said "2to3", i didn't mean't the tools at all. Rather the fact we have to handle the migration, my sentences was poorly worded. > I'm not sure about "twice the work": you don't need to track twice the > software releases (except for the interpreter itself), or twice the > upstream patches, etc. Well, if we handle this like 2 separates languages, that mean 2 separates rpms for each modules. Or we should be clever when generating 1 rpm to have the modules for both python 3 and python 2 generated ( Except when the developper did choose to have separate tarball or code base ) Having one rpm that produces 2 modules also mean that we will rebuild all modules for python3 and all for python2, and I know that for example Buchan will not like the extranous trafic it would generate. So IMHO, there is various things to discuss. -- Michael Scherer