Justin Pryzby <[EMAIL PROTECTED]> 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]