[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 [...] > The way you describe it makes it sound like architecture: all packages > will now need to depend on python-all-dev and install their files for > all supported Python versions so that symlinks are created this way. python-all, not python-all-dev, but that's correct. > 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). > 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. > > - create simple maintainer scripts with pycompile and pyclean > > commands and (if needed) rtupdate script (for private directories that > > use default Python version and will most probably work with next default > > version). Private modules that cannot be used with default Python version > > will get additional pycompile command with all needed arguments, like > > minimum required Python version or hardcoded version in both, maintainer > > and rtupdate scripts, > > This part looks worrysome to me. Putting the complexity of the > installation/cleanup actions in auto-generated maintainer scripts (and > now auto-generated rtupdate scripts) sounds like reproducing one of the > core design errors of python-central. The more complexity you put in > auto-generated scripts, the less chances you leave for the system to > clean itself up by just upgrading the helper scripts in case of a bug. 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). 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). [...] > > $ grep foo debian/python-foo.prerm > > dpkg -L python-foo | pyclean > > Ugh. Use 'pycompile python-foo', pretty please. [...] > > $ grep privatedir debian/mypackage.postinst > > dpkg -L mypackage | pycompile /usr/share/privatedir1 > > dpkg -L mypackage | pycompile /usr/share/privatedir2 -V 2.4 > > Ugh again. How about that? > pycompile -p mypackage /usr/share/privatedir1 ok, `pycompile -p python-foo` and `pycompile -p mypackage \ /usr/share/privatedir1` it is. > 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. > Overall, I’m still dissatisfied with this proposal. > > First of all, for private modules, it has absolutely zero interest, and > only consists in regressions. I don’t see the point in the proposed > changes for private modules, apart from introducing a third helper tool > with less features than both existing ones. maintainers of packages with private modules only will not see many advantages over pysupport or pycentral, agreed. [...] > For architecture: all packages, I’m still not convinced. Having to > rebuild these Python packages means roughly 3 times as many packages to > rebuild during transitions as there are now. This is going to make > transitions a *lot* more complicated. This means much more work for > everyone, including the RT, at times of changing the list of supported > Python versions. We also lose the current potential to have a large > subset of the archive immediately available for a new Python version > when it becomes ready. that's the main disadvantage, I agree. It's not that we change the list of supported Python versions that often, though... -- 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
Attachment:
signature.asc
Description: Digital signature