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? The time between stopping and restarting the daemon? In this case, the package needs to be adapted so that the daemon is restarted - or even better, told to restart itself through a signal - in the postinst without being stopped in the prerm. > > 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. > > 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. > > > - 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). How do you fix autogenerated .rtupdate scripts without rebuilding all 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. > ok, `pycompile -p python-foo` and `pycompile -p mypackage \ > /usr/share/privatedir1` it is. Much better indeed. > > 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. > > 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... No, but when it happens, will you still find people to schedule hundreds of boring, manual uploads? What is the gain here? Cheers, -- .''`. Josselin Mouette : :' : `. `' “A handshake with whitnesses is the same `- as a signed contact.” -- Jörg Schilling -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
