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, -- It is easy to love a country that is famous for chocolate and beer -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26 -- 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/20141124021551.ga26...@grep.be
