Re: On robustness of maintainer scripts
[Jakub Wilk, 2013-05-12]
> * Piotr Ożarowski <piotr@debian.org>, 2013-05-11, 00:29:
> >why not generate maintainer scripts without pycompile at all?
>
> - There are hundreds of packages that use py{compile,clean} in the
> maintainer script. The script needs to continue to exist at least
> until jessie is released.
true, but we will get rid of it in jessie+1, not in jessie
> - Fixing the problem in py{compile,clean} means that even the
> packages that haven't been rebuilt can benefit from the fix.
that's why I want to keep it simple in maintainer scripts. dh_python2
knows for which versions given directory has to be bytecompiled, so why
not hardcode these directories in maintainer scripts (and use dpkg -L
<package> | grep <dir> to fill todo files).
> - If you take all corner cases into cosideration, the required gets
> pretty complicated. IMO too complicated to risk putting the code
> directly into maintainer scripts.
if we get rid of exclude patterns (and not a single package in unstable
provides a file in /usr/share/python/bcep/ directory, so it's not really
needed apparently) there are not that many features in pycompile...
Maintainer scripts can simply create missing namespaces and then let
interpreter packages know which files they should bytecompile (by
creating todo files for X.Y or default interpreter).
pycompileX.Y (provided by interpreter package and invoked by dpkg
trigger) can read such files and bytecompile all files listed there
(rt* scripts can do similar thing)
[...]
> Here you need to check with versions are supported, and which of them
> are installed^Wunpacked.
>
> Oh, and the call to dpkg-trigger is missing. /o\
shebang is missing too! ... you know it was just an example to
demonstrate the idea and not the final code, right? :)
--
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
Reply to: