Proposal to avoid file overlaps

[Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>]

Hi,

Some further problems have come up, some having to to with the
suggetsion of having all arch use the same name for lib packages.
Broadly this is all about the i386 and amd64 package having file
overlaps. Broadly this is how to reduce the amount of splitting we
have to do for packages that have to be installable for two archs.


mrvn@dual:/usr/share/doc% ls | wc
    623     623    7215
mrvn@dual:/usr/share/doc% ls * | sort | uniq -c | sort -n
...
     25 NEWS.Debian.gz
     31 README.Debian.gz
     31 TODO.gz
     59 AUTHORS
     70 TODO
     93 examples/
     98 NEWS.gz
    102 README.gz
    149 README
    157 README.Debian
    399 changelog.gz
    514 changelog.Debian.gz
    576 copyright

As you can see there are a few files that "every" package has. Some
are required by policy (and its strange that some are missing its
copyright).

If we have libfoo/amd64 and libfoo/i386 at least copyright and
changelog will allways conflict as well as var/lib/dpkg/info/*. The
former can't even be split out into libfoo-common even if we would
like to. (Re)moving the copyright would be a legal problem I
think. The later are dpkg internal files so it can just add the
subarch to them. Havin libfoo and lib64foo saved us from this one so
far.

But similar problems happen in /usr/lib/package, /usr/share/package
and /usr/include/package.


/usr/lib/package should probably follow ${libprefix} as set by
autoconf wich would result in /usr/lib64/package on amd64 and resolve
that problem. Binaries can use /usr/lib/package or /usr/lib64/package
since they don't have to be installable in parallel. Any objections to
that part?


For /usr/share/doc/package I suggest dpkg moves it to
/usr/share/doc/arch/package/ and the best arch (according to
subarchtable) is linked to /usr/share/doc/package. Docs are assumed to
be near identical but we don't want (and can't for copyright and
changelog) to split them out of the main package if they are small. If
the amd64 docs being linked into /usr/share/doc/package instead of the
i386 docs causes a problem  I would say the package is buggy. If the
arch is relevant (e.g. in example files) the docs should add it to the
filename in a way that pleases them (Readme.i386, readme.amd64). The
source would already contain a bunch of Readmes one for each arch with
different names or dirs.


For /usr/share/package I suggest we do the same. Policy says they have
to be shareable between different archs so sharing them between
compatible archs is fine.


For /usr/include/package I'm at a loss. I assume all header files can
use "#ifdef __AMD64__ #elif __I386__ #endif" constructs if they need
that and don't already do it. That means header could be split out
into libfoo-common-dev packages and both libfoo-dev packages would
depend on that.


Anything not contained in the above dirs but still in some library
package I suggest forcing a split into libfoo and libfoo-common or
moving it into arch specific places.

MfG
        Goswin