On Monday, November 24, 2014 03:15:51 Wouter Verhelst wrote: OK. I'm back on this again.
> On Sun, Nov 23, 2014 at 03:29:29PM -0500, Scott Kitterman wrote: > > On Sunday, November 23, 2014 13:41:47 Wouter Verhelst wrote: > > > As I understand the situation, that won't solve your problem. > > > > > > If python pre-depends on python-minimal (and the rest of the > > > dependencies > > > stay in place), then you have the following situation: > > > > > > - python2.7-minimal and python-minimal are unpacked (in undefined order) > > > - python2.7-minimal is configured > > > - python-minimal is configured > > > - python can now be unpacked > > > > > > As such, rather than fixing your problem, it would make matters worse; > > > today it sometimes fails, depending on the exact decisions that apt and > > > dpkg take when installing packages. With a pre-depends, it would > > > *always* fail on new installs, because python would then not be > > > *allowed* to be unpacked if python2.7-minimal isn't on the system, whose > > > postinst would fail, which would forbid the installation of python (the > > > step necessary to configure python2.7-minimal). > > > > > > It looks to me like the only solution here is to split off whatever it > > > is that python2.7-minimal needs from the python package into a separate > > > package, and have python2.7-minimal depend on that separate package. > > > Call it "python-base" or "python-common" or something. > > > > Why would python-minimal be configured at unpack time for python? AIUI, > > the pre-depends would just require python-minimal to be unpacked prior to > > configure, not unpack. > > No, that's what a regular depends does. A pre-depends requires a package > to be configured before unpack. > > Policy 7.2: > > "This field is like Depends, except that it also forces dpkg to > complete installation of the packages named before even starting the > installation of the package which declares the pre-dependency, as > follows: > > When a package declaring a pre-dependency is about to be unpacked the > pre-dependency can be satisfied if the depended-on package is either > fully configured, or [special case for upgrade rather than install]" > > > Did you mean python can now be configured? > > > > I think pre-depends would solve the problem at hand, > > Unless I misunderstand the situation and your proposed solution, it most > certainly will not. > > If what you mean is: > > python pre-depends python-minimal > python-minimal depends python2.7-minimal > > Then a pre-depends is *not* what you need. If you mean something else, a > Pre-Depends is probably still not what you need, because the cases in > which a Pre-Depends is useful are actually pretty rare (I suspect that's > why policy tells you to ask on this list before using it...). They are > limited to two cases: > > - Your preinst (as opposed to your postinst) wants to use something that > is *not* in the set of Essential packages, or > - Your package wants to install files in a "special" directory which > only exists in a "working" state if another package was installed > first (e.g., multiarch-support) > > > but I'm also interested in feedback on the alternative proposed in the > > bug: > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769106#31 > > As long as an installation of python2.7-minimal without python2.7 will > not break if the "rtinstall" script isn't run, that really looks like an > alternate proposal of my "python-base"/"python-common" suggestion. > > What you need is for any scripts or binaries which you run in your > postinst to be installed by packages that are either available in the > Essential set, or in the set of packages that you depend on, directly or > indirectly, through a depends or pre-depends. As long as you follow that > rule, you're safe. A _reverse_ dependency (i.e., a package that depends > on _your_ package) cannot safely provide a script or binary to be used > in your postinst; and it does not matter whether you're using Depends or > Pre-Depends in that case, because for postinst there is no difference. > > Regards, That's not the case here. In the original bug [1], the situation is that during jessie development texlive-music gained a dependency on python, so on upgrade, python gets installed. As part of that installation, the public_modules.rtinstall hook gets run as part of the python2.7-minimal postinstall. For the post-install script to succeed, both python and python-minimal need to be unpacked. They don't need to be installed. Also from policy 7.2: > A Depends field takes effect only when a package is to be configured. It > does not prevent a package being on the system in an unconfigured state > while its dependencies are unsatisfied, ... That's the case we have here. python has been unpacked, but not configured, so it'd dependency on python-minimal is irrelevant. Later in 7.2, it goes on to say: > Pre-Depends This field is like Depends, except that it also forces dpkg to > complete installation of the packages named before even starting the > installation of the package which declares the pre-dependency, as follows: > When a package declaring a pre-dependency is about to be unpacked the > pre-dependency can be satisfied if the depended-on package is either fully > configured, or even if the depended-on package(s) are only in the > “Unpacked” or the “Half-Configured” state, provided that they have been > configured correctly at some point in the past (and not removed or > partially removed since). In this case, both the previously-configured and > currently “Unpacked” or “Half-Configured” versions must satisfy any version > clause in the Pre-Depends field. So with a pre-depends, dpkg would install python-minimal before python was installed. At the point the texlive-music would run, python-minimal would be installed (or under some conditions at least unpacked) and python would be at least be unpacked. I've created a local package with the pre-depends added and it works. Without the pre-depends, the sequence is (as in the bug log): Unpack python Unpack python2.7 Unpack python2.7-minimal Unpack libpython2.7-minimal Configure libpython2.7-minimal Configure python2.7-minimal python or pycompile not found in public_modules.rtinstall hook. Boom. Upgrade fails. With the pre-depends, the sequence is: Attempt to unpack python and not do it due to pre-depends Unpack python-minimal Unpack python2.7-minimal Unpack libpython2.7-minimal Configure libpython2.7-minimal Configure python2.7-minimal (which succeeds now due to python-minimal being unpacked) Configure python-minimal Unpack python2.7 Unpack python Configure python2.7 Configure python Then do texlive-music upgrade. While I understand the general concern about sequence of package installs would lead you to believe that adding the pre-depends would make python2.7- minimal uninstallable, it actually doesn't. python-2.7-minimal uses the .rtinstall hook conditionally (from the python2.7-minimal postinst): for hook in /usr/share/python/runtime.d/*.rtinstall; do [ -x $hook ] || continue $hook rtinstall python2.7 "$2" "$version" done If python2.7-minimal is installed first, there are no hooks in /usr/share/python/runtime.d/ so there is no problem. I understand this isn't ideal, but I still think it's the shortest, safest path to having the RC bug fixed. Scott K [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769106 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1783236.fitYKYjlcS@scott-latitude-e6320
