Your message dated Fri, 06 Oct 2006 14:24:11 -0600
with message-id <[EMAIL PROTECTED]>
and subject line fixed at some point in the past
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--- Begin Message ---
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)
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".
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
--- End Message ---
--- Begin Message ---
Hi,
It looks like this was fixed at some point prior to the version in the
current Stable using the Perl command:
$binaryprefix =~ s,/*$,/, if length($binaryprefix);
mentioned in:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=35654;msg=10
...closing.
- Bruce
--- End Message ---
