[Josselin Mouette, 2010-01-22] > Le mardi 19 janvier 2010 à 20:45 +0100, Piotr Ożarowski a écrit : > > [Josselin Mouette, 2010-01-19] > > > Le vendredi 15 janvier 2010 à 11:58 +0100, Piotr Ożarowski a écrit : > > > > - starting/stopping daemons problems (very long downtimes due to byte > > > > compilation via triggers) in pysupport, > > > > > > This is only a problem for daemons using namespace packages, which you > > > can count with one hand’s fingers. > > > > it takes too long even when I run `dpkg -i foo.deb`, IMHO > > What takes too long?
I just run `dpkg -i python-routes_1.11-1_all.deb` 4 times and pysupport's triggers needed 6, 7, 6 and 5 seconds to byte compile 8 .py files on Core 2 Duo @ 2.33GHz. compileall.py needed 0m0.048s to do the same. I will try to debug (& fix) it after cleaning my TODO a little bit. > > > This is another big regression for packages that don’t use distutils / > > > setuptools / whatever crap upstreams invent. Currently, for > > > architecture-independent packages, you can use whatever build system is > > > shipped, close your eyes, run dh_py* and get done with it. With your > > > proposal, it means that *all* archirecture-independent packages would > > > require adaptation to loop over supported Python versions. > > > > Since binary packages will have hardcoded list of supported Python > > versions, why not additionally test these versions at build time instead > > of install time? If it really is a problem to install for all > > supported Python versions, I can add something like "-V 2.5+" in order to > > create symlinks for missing .py files and bytecompile for installed > > versions only, but I'd strongly encourage developers to add python-all to > > Build-Depends-Indep anyway (so that I could test them and FTBFS if > > needed). > > I don’t think you understand the problem here. For example, if a package > uses the autotools instead of distutils, it will require lots of changes > in debian/rules. Multiply them by all packages not using distutils and > have fun. I already wrote that I will add -V option (I would have to do it anyway, as I want to also prepare dh_pycentral replacement) > > > This is a huge task, and a complete waste of time. Don’t forget that > > > most people that were motivated to work on Python packages are tired of > > > endless changes that had to be done in hundreds of packages because of > > > thoughtless changes in core Python packages. > > > > I'll do my best to make it work even without changes in packages that > > currently use pycentral or pysupport. > > How would it work? Currently the proposal doesn’t describe that. by replacing dh_pycentral with dh_python wrapper (note that dh_pycentral is invoked only at build time) > > I see it the other way around: short scripts will allow me to fix things > > in /usr/bin/py* commands instead of requiring to rebuild all packages > > (problem we currently have with Lenny's pycentral based packages). > > How do you fix autogenerated .rtupdate scripts without rebuilding all > packages? if all what this autogenerated .rtupdate script does is invoking another script (with a set of args) provided by python package, in most cases it should be enough to fix python package's script. That's what you do f.e. in maintainer scripts generated by python-support, no? You fix update-python-modules instead of regenerating packages. > > Please note that even if something will fail in maintainer script, the > > package will still be usable (.py files are already in the final > > location). > > That’s until you discover a new way for the scripts to fail - although I > agree that in theory, there should be less problems. I can use: `pycompile ... || true` for public modules (and I consider it a great advantage over pysupport/pycentral) > > > Or even better, always "pycompile mypackage", and ship the list of > > > directories to byte-compile in a file. > > > > I want to avoid shipping additional files or hardcoding list of files in > > maintainer scripts. I see no problem in merging package contents with > > pycompile command line options. > > The problem will come if you ever change the exclusion lists of what > needs and needs not to be byte-compiled. All my exclusions will be either hardcoded in pycompile argv (private dirs and few broken public modules) or in pycompile sources (i.e. I can use package contents). Only the first one requires rebuilding a package if something will not work correctly. -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
signature.asc
Description: Digital signature
