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/ slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: Digital signature
