reassign 410951 r-other-gking-matchit
tags 410951 -pending
thanks

On Fri, Mar 02, 2007 at 04:19:15PM -0300, Gustavo Franco wrote:
> reassign 410951 r-cran-matchit
> tags 410951 pending
> thanks

> I've found that r-other-gking-matchit sarge to etch upgrade fails due
> to the relaxed dependency on r-cran-matchit [ Depends: r-base-core (>>
> 2.2.0) ], if r-cran-matchit works with r-base-core >= 2.4, please
> update the Depends field to >= 2.4.0.20061125-1, otherwhise
> r-other-gking-matchit, r-cran-matchit and maybe others should be
> removed.

> The error message is due to the missing ldpaths on r-base-core 2.2
> that is running in the sarge system and satisfies the r-cran-matchit
> dependency. ldpaths exists on r-base-core 2.4 though.

I don't see any problems with the dependencies of r-cran-matchit. 
r-cran-matchit has a correct, *versioned* dependency on r-base-core (>>
2.2.0).  This isn't satisfied by any r-base-core package in sarge, only by
the r-base-core_2.4.0.20061125-1 package in etch.

Furthermore, it's not r-cran-matchit that's failing here.  This failure is
from the postrm of the *old* version of r-other-gking-matchit, which depends
on having a fully-configured r-base-core package installed at the point of
postrm upgrade -- a condition which is not guaranteed by policy.

The new version of r-base-core is /unpacked/ at this stage, but
/usr/lib/R/etc/ldpaths is left as a dangling symlink pointing to
/etc/R/ldpaths, which is only created in the r-base-core postinst.

So the real bug is in the postrm of the old version of r-other-gking-matchit
in sarge.  

Here's the full sequence in more detail, from an aptitude dist-upgrade:

[...]
Preparing to replace r-base-core 2.1.0-1 (using 
.../r-base-core_2.4.0.20061125-1_i386.deb) ...
Unpacking replacement r-base-core ...
[...]
Unpacking replacement r-other-gking-matchit ...
/usr/bin/R: line 113: /usr/lib/R/etc/ldpaths: No such file or directory
dpkg: warning - old post-removal script returned error exit status 1
dpkg - trying script from the new package instead ...
dpkg: error processing 
/mirror/pool/main/m/matchit/r-other-gking-matchit_2.2-11-1_all.deb (--unpack):
 there is no script in the new version of the package - giving up
[...]
Selecting previously deselected package r-cran-matchit.
dpkg: considering removing r-other-gking-matchit in favour of r-cran-matchit ...
dpkg: yes, will remove r-other-gking-matchit in favour of r-cran-matchit.
Unpacking r-cran-matchit (from .../r-cran-matchit_2.2-11-1_all.deb) ...
/usr/bin/R: line 113: /usr/lib/R/etc/ldpaths: No such file or directory
dpkg: error processing 
/mirror/pool/main/m/matchit/r-cran-matchit_2.2-11-1_all.deb (--unpack):
 subprocess post-removal script returned error exit status 1
[...]
<snip bit where dpkg becomes impressively confused about whose postinst is
whose, and gives a postrm error from sudo citing the same problem>
[...]
Setting up r-cran-matchit (2.2-11-1) ...
Reading Package Lists... Done             
Building Dependency Tree       
Reading extended state information      
Initializing package states... Done
$ dpkg -l r-other-gking-matchit
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name           Version        Description
+++-==============-==============-============================================
iH  r-other-gking- 1.0-1-1        GNU R package of nonparametric matching meth
$

Note that at this point, it's trivial to get r-other-gking-matchit properly
installed -- all it takes is a second aptitude dist-upgrade or a dpkg
--configure --pending.  But it does add to the complexity of the upgrade
path, and each bug like this increases the probability that a user will end
up with a wedged system in the middle of an upgrade.

So I'm reassigning this bug back to r-other-gking-matchit, which is both the
package with the bug and the only package that can fix the bug.  In this
case, the fix is simple: all we need is a no-op postrm script to be included
in the new version of the r-other-gking-matchit package, which will handle
the failed-upgrade case gracefully.

For reference, the only thing that the old version of r-other-gking-matchit
does in its postrm is:

        R CMD perl /usr/lib/R/share/perl/build-help.pl --htmllists

If that's actually an important thing to have done during the upgrade (the
new version of r-other-gking-matchit no longer does this), then it can be
cleaned up in the postinst instead.

Cheers,
-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
[EMAIL PROTECTED]                                   http://www.debian.org/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to