[Mageia-dev] Python Packaging Policy

Wed Jan 19 08:25:23 CET 2011

On Wed, Jan 19, 2011 at 02:07:18AM +0100, Antoine Pitrou wrote:
+> On Wed, 19 Jan 2011 00:55:40 +0100
+> Michael scherer <misc at 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
+