[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#35654: dpkg & predeps [FIX incl.]

reassign 35654 dpkg

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.

> =========
> 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 = \

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: