Re: binary-alpha and binary-sparc directories

[Raul Miller <rdm@tad.micro.umn.edu>]

Juergen Menden:
   any package which needs to be compiled is of course not
   arch-independent.  on my system here (sunos, not debian ;-)) at
   least the following are partially compiled:

   > ii  dvips            5.58f 2    TeX DVI-driver for Postscript
   > ii  fort77             1.6 1    An f2c front end to make it look like a 
   > ii  makeidx           2.12      Makeindex, a general purpose index proce
   > ii  metafont          2.71 2    Metafont - TeX's font engine
   > ii  xdvi              1.8f 2    A TeX DVI-previewer for X11
   ...

It does look like dvips was superceeded by some other package, and
that it did originally have some executables in it.  [All I have on my
system from dvips is a copyright statement and some .tex
files].  makeidx, metafont and xdvi also seem to be mere stubs of
packages on my system.

/usr/bin/fort77 is a perl script, the only other things I see in this
package are a man page and a copyright statement.  Since I have f2c on
my system as a separate package, I'd guess that fort77 has also been
superceeded...

I think this is a bug in the debian packaging mechanisms.

The current mechanism presumes that files of the same name are drop-in
replacements for each other.  It currently manages the archive by
removing all references to a file but the most recent package to
provide the file.  This was conceived of as a way of managing packages
which are partially provided for on the base disks.

However, a better way of managing base packages is to record the
partial installation of the packages and mark them with a suitable
status code (for example, "unpacked").  Then, when they're installed
"for real" dpkg can treat these the same as any other incomplete
package installation.

For the more general case of packages which inadvertently provide the
same facilities, when one of the packages is removed the other may
become nonfunctional.

It's perfectly all-right for the most recent package to be installed
to provide the files for an ambiguous case.  But, the fact that
another package needs the file should also be recorded.  Only one
package can have supplied the physical instance of the file, but the
file might be included with more than one package.

Or, perhaps it would be simpler for dpkg to protest and refuse to
install a package if it has a file-overlap with another package?

Either way, the present behavior invites errors.

-- 
Raul