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¹
> | 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.
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.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: Digital signature
