On Tue, May 21, 2013 at 05:55:58PM +0200, Matthias Klose wrote:
> >> | 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.
That makes sense to me. Would that code be able to live in a trigger?
(Bearing in mind that a trigger can't doesn't get told *where* the new files
are)
> > # 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.
Essential packages are *required* to deal with library dependencies as
pre-dependencies. So this is specific to python, in the sense that python
is being called from maintainer scripts before the package has been
configured.
I think the pre-depends is the right change here; but as Aurelien points
out, pre-dependencies are supposed to be discussed on debian-devel because
they can have system-wide repercussions. Can you please kick off a thread
to discuss this there?
> 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.
Having the debconf package break during upgrades because it tries to call
python and fails looks like a pretty serious bug to me. I'm not sure about
what the right way to *fix* it is, but we definitely don't want users'
upgrades to blow up...
--
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/
slangasek@ubuntu.com vorlon@debian.org
Attachment:
signature.asc
Description: Digital signature