Re: /usr/share and -common pkgs
Justin Pryzby <justinpryzby@users.sourceforge.net> writes:
> -common packages are used to reduce the size of the archive; arch
> independant data need not be included in each of the 10+ arch-specific
> binary packages; only one package is needed.
>
> As expected, most of the contents of the -common packages are in
> /usr/share:
>
> time zgrep -Ff <(apt-cache search -n -- -common |sed -ne 's/[^a-z0-9.+-].*//; s/^/\//; /-common/p') /home/pryzbyj/conflict/Contents-i386.gz |grep -Eo '^(usr/)?[^/]*' |uniq -c |sort -nr
> 46366 usr/share
> 3319 usr/lib
> 586 etc
> 298 var
> 165 usr/bin
> 133 usr/include
> 83 usr/sbin
> 6 sbin
> 3 usr/games
> 3 usr/X11R6
>
> The LFS intent of separating /usr/share and /usr/lib is to allow a
> filesever to export /usr/share to machines of *any* architecture
> running the same OS (/usr is supposed to be sharable to machines of
I think that has been nearly completly abandoned in practice. Harddisk
space is just too cheap and debian never actualy supported this on a
package manager level (e.g. let dpkg know the server has /usr/share so
skip it on extract).
> the *same* arch). But this is considerably complicated by the fact
> that many packages *depend* on their -common data (90), or the other
> way around (20); some both (12) [out of 271]:
Depends both way is a policy violation because it makes the package
(theoretically) uninstallable. It also leats to install/remove
failures if the postinst/prerm uses the other package since they will
be installed/removed in random order. This often damages the buildd
chroots leaving a broken setup behind.
> apt-cache search -n -- -common |sed -ne 's/[^a-z0-9.+-].*//; h;G; s/\n/ /; s/-common//p;' |while read p q; do r=`apt-cache show $q 2>/dev/null || continue`; grep -q "^Depends:.* $p[ (,]" <<<"$r" || continue; echo $p; done
>
> Twiddle the p's and q's and second || to && to taste.
>
> Years ago I asked Zed Pobre about this, and he said that the arch and
> indep packages should recommend each other; in the typical case, they
> should both be installed; in the fileserver case, only arch is
> installed on the clients; only indep on the server.
>
> Is this recommendation widely accepted, or just for cases where
> likeliness of using a fileserver is relatively high? Should policy
> make a recommendation^W^W^W^Wbugs be filed? If not, what is the
> suggested way to run such a fileserver setup for these packages?
> equivs?
If package A needs something from package B to run then you need a
depends. If package B is just some optional themes or icons then a
recommends/suggests will suffice. In that case B should probably also
say Enhances: A. A recommends will not (mostly not) cause B to get
installed at all. It is only a recommendation while depends reflects a
requirement.
I guess you could write a script that generates pseudo packages for
all -common packages that check that it is installed on the server in
preinst or some other safety measure and use them instead for a shared
/usr/share setup. That won't help with packages that mix /usr/share
and other files though. A lot of packages do mix /usr/share and other
stuff even if you exclude /usr/share/doc. I fear that you need to
patch dpkg or dpkg-deb to support this.
> Please Cc: me.
> Justin
MfG
Goswin
Reply to: