Re: Bug#35654: dpkg & predeps [FIX incl.]
reassign 35654 dpkg
thanks
J.A. Bezemer wrote:
> Package: dpkg-multicd
> Version: 0.14
>
> Urgency: high (I don't like angry customers ;-)
>
>
> There's something wrong with the handling of predeps with multi_cd (and I
> think any other dselect method!!).
>
> I don't know if this is fixed already - I didn't check other bug reports.
>
> If this report should be forwarded to other packages as well, please feel
> free to do so.
>
>
> FIX:
> ===
> in /usr/lib/dpkg/methods/multicd/install, search for `p_main_binary',
> which occurs exactly once, in the line
>
> ' -- "$p_mountpoint$p_main_binary" "$predep" "$thisdisk"
>
> This line should be changed to
>
> ' -- "$p_mountpoint$p_hierbase" "$predep" "$thisdisk"
>
> (the same can/should be done for all other methods)
I guess, I know the reason for this. Pre-Dependencies could only be
main packages.
>
> RATIONALE:
> =========
> This is really a weird problem, that (in the users' view) does only occur
> with netscape-base-4 (pre-depended by netscape-base-406,407 and 45). And
> it only occurs if you have netscape on a `non-free' CD, like the one that
> I'm producing for sale in the Netherlands.
>
>
> When multicd/install is installing pre-deps (which it does before the
> `real' installing), it needs the correct filenames. This is done by
> concatenating $binaryprefix and $filename[$i]. $filename[$i] is the name
> that is specified in the `Filename:' line in the Packages.cd file.
> $binaryprefix is (currently) $p_mountpoint$p_main_binary.
>
> Let's have an example:
> $filename[$i] = "dists/stable/main/binary-i386/sect/file.deb"
> $p_mountpoint = "/var/lib/dpkg/methods/mnt"
> $p_main_binary = "/debian/dists/stable/main/binary-i386"
> (_these_ values are correct)
>
> Then
> $binaryprefix = \
> "/var/lib/dpkg/methods/mnt/debian/dists/stable/main/binary-i386"
>
> and multicd/install searches for the file
> /var/lib/dpkg/methods/mnt/debian/dists/stable/main/binary-i386/dists\
> /stable/main/binary-i386/sect/file.deb
>
> This obviously is incorrect, and multicd/install doesn't find that file.
> But there is a `escape route' (or maybe a bugfix??): when no matching file
> is found, multicd/install invokes `find' to look for a file that matches
> the basename that is wanted, in our example: "file.deb".
You have overseen this command:
$binaryprefix =~ s,/*$,/, if length($binaryprefix);
so $binaryprefix = \
"/var/lib/dpkg/methods/mnt/debian/dists/stable/main/"
But basically you're correct, there is a bug :)
Thanks *A LOT* for the detailed investigation. I've fixed this. I'm
reassigning this but to the dpkg since the bug is present in the original
method as well.
> This searching has $binaryprefix as a starting point, so searching occurs
> in the hierarchy under
> /var/lib/dpkg/methods/mnt/debian/dists/stable/main/binary-i386
> and sect/file.deb is found easily.
>
> No problem whatsoever (in the view of the user). The package name is
> found, and installation procedes normally.
>
>
> However, with netscape-base-4 there is a problem. Of course,
> /var/lib/dpkg/methods/mnt/debian/dists/stable/main/binary-i386/dists\
> /stable/contrib/binary-i386/web/netscape-base-4.....deb
> is not present, so `find' is tried. But searching occurs from
> /var/lib/dpkg/methods/mnt/debian/dists/stable/main/binary-i386
> and this way, netscape-base-4, that is in _contrib_, is not found at all.
> Big problem, angry users, etc.
>
>
> The solution of the FIX above is simple. $binaryprefix should not be
> /var/lib/dpkg/methods/mnt/debian/dists/stable/main/binary-i386
> but just
> /var/lib/dpkg/methods/mnt/debian
> and given that
> $p_hierbase = "/debian"
> we can use that to create $binaryprefix = $p_mountpoint$p_hierbase
>
> This way, the first constructed filename is
> /var/lib/dpkg/methods/mnt/debian/dists/stable/contrib/binary-i386\
> /web/netscape-base-4.....deb
> which is correct. And if the file is really out of place, searching
> occurs from
> /var/lib/dpkg/methods/mnt/debian
> which covers main as well as contrib, so the file is found no matter where
> it's hiding.
>
>
> There is only one problem (`known bug') introduced by this way of fixing,
> but I don't think that will be a big problem. If `find' must be used (i.e.
> if the Packages file is wrong), searching will occur in all architecture
> subdirs that are present. So, in our example, netscape-base-4 may be found
> more than one time, if contrib/ of more architectures is present. I really
> don't know what will happen in such a case.
>
> Of course, there is a fix for this problem. If more than one file is
> found, there could be a selection that first discards all
> */binary-(!$arch)/* names. (No, not a selection that _keeps_ only
> */binary-$arch/* names, that might delete some right ones).
>
> But this still doesn't work if you have a really garbled "copy" of the CD.
> So I don't really recommend this second fix.
>
>
> Regards,
>
> Anne Bezemer
>
--
The good thing about standards is that there are so many to choose from.
-- Andrew S. Tanenbaum
Please always Cc to me when replying to me on the lists.
Reply to: