Re: On robustness of maintainer scripts
Am 13.05.2013 19:21, schrieb Steve Langasek:
> On Sat, May 11, 2013 at 12:29:07AM +0200, Piotr Ożarowski wrote:
>> [Jakub Wilk, 2013-05-10]
>>> postinst ========
>> [...]
>>> Proposed solution: 1) Wait until #671711 is fixed. 3) Make pycompile a
>>> shell script that does only two simple things: - write options it was
>>> called with to a file, say, /var/lib/python/pyX.Ycompile.todo; - use
>>> dpkg-trigger to trigger pythonX.Y.
>
>> why not generate maintainer scripts without pycompile at all? I wanted to
>> delegate as much as possible to interpreter packages, but your idea with
>> temp. files is even better - maintainer scripts can look like this:
>
>> | touch /usr/lib/pythonX.Y/dist-packages/namespace/__init__.py¹ | touch
>> /usr/lib/pythonX.Z/dist-packages/namespace/__init__.py¹
namespace packages aren't an issue anymore in python3, and for python2 it
would be better to ship these files into separate binary packages. these
aren't that many, and it would be much better for the robustness. nothing to
do anymore about these in maintainer scripts.
>> | dpkg -L <package> | grep \.py$ | while read file | do | echo "${file}"
>> >> /var/lib/python/pyX.Ycompile.todo | echo "${file}" >>
>> /var/lib/python/pyX.Zcompile.todo | done
>
> The disadvantage is that the more logic is included directly in the
> maintainer scripts, the harder it is to fix any bugs with that logic
> because every package that includes the buggy behavior needs to be fixed.
> Even if that's only a simple rebuild with an updated version of dh_python2,
> it's quite costly to do that over all the affected packages in the
> archive.
>
> So from a robustness standpoint, it would be preferable if this logic
> could be encapsulated, if not in pycompile (for the reasons described),
> then at least in a trigger.
If it needs to be encapsulated, then it should be in the pythonx.y
packages shipping the interpreters, even if it does mean to duplicate these
scripts up to two times.
My hope was that most of the code for pycompile would end up in py_compile.py,
and the pycompile script would rely on that. But that didn't happen.
Depending on the complexity of the resulting pycompile, it could be inlined in
maintainer scripts, but it doesn't have to be.
> For my part, I'm having a hard time understanding why any of the proposed
> changes here are warranted. Yes, there are corner cases where the current
> maintainer scripts will fail, but the "real-world failures" included in
> Jakub's original mail seem to reduce to bug #680930 (which I think it was
> reasonable to fix by changing the interpreter package's linkage) and bug
> #671711 (which is an obviously unacceptable bug in dpkg that needs to be
> fixed). The other bugs, such as bug #706758, seem to map to these
> directly (i.e., it's fixable by applying the same change for bug #680930 to
> the python2.6 package in wheezy - currently this fix has only been applied
> for python2.7); and I don't think that any problem that requires a command
> like this in a minimal reproducer case:
>
> # dpkg --force-depends -r libssl0.9.8
>
> ... should seriously be considered a high priority, and be allowed to
> dictate the design of the interpreter handling.
>
> Relying on packages to be usable when unpacked-but-not-configured is
> fragile. But I am not convinced that the proposed cures are not worse
> than the disease.
>
> Certainly if we want to continue using pythonX.Y from maintainer scripts
> the way we do currently, great care would need to be taken to ensure
> they're usable when unpacked - which means a committment to either not add
> new library dependencies to the interpreter or ensure new library deps are
> listed in pre-depends instead of depends. Yet I think this should be
> entertained as an alternative to increasing the amount of code duplicated
> across hundreds of maintainer scripts.
python2.7-minimal shouldn't get any more dependencies on libraries. Now the
version in unstable depends on libc6, libgcc1, zlib1g. The libgcc1 dependency
comes from a linker bug when built with -flto and is dropped once linked with
ld 2.23.x. zlib is needed in the interpreter for the zip file support. From
what I can see, it would be hard to drop. libc6 is interesting in that the
update to 2.17 causes #708831, which I now worked around by making libc6 a
pre-dependency. I don't think this is specific for python2.7-minimal, and will
be exposed by other packages as well, as long as some essential packages like
coreutils and perl are rebuilt against the new libc6.
Afaicr, adding trigger support in some helpers did introduce its own set of
upgrade issues, but this might be safe, if no helpers use triggers to generate
and update symlink farms.
I don't share the opinion on the severity of #709198, and how it should be
fixed, if we are going this route of keeping the python interpreter working
during upgrades.
The dependency of python2.7-minimal on libpython2.7-minimal looks safe to me,
I don't think it needs to be raised to a pre-dependency.
Matthias
Reply to: