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

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

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


Reply to: