Re: New pre-depends: python pre-depends python-minimal
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
Reply to: