Adam C Powell IV wrote: > Hmm, why does it need to "dynamically" change links in /etc/alternatives? > > I guess the question is better asked this way: do people NFS-mount /etc?! > (It's > just 3 MB on my system!) If yes, then you're right, we'd need > /var/alternatives, as that would have to be a local fs, right? If no, then > installing any package involving /etc/alternatives on such a network involves > hand-creating the links at *install time* (not boot time or run time) anyway, > so > what's the difference?
You can mount /etc read-only currently. In FHS terms, /etc can be static-unsharable^1. Most of /var is variable-unshareable. Updating /etc/alternatives on boot requires /etc to be read-write when executing the init scripts. What I'd suggest is a facility similar to update-alternatives, but based on automatic selection by sub-architecture. The cleanest way to do this is to define a set of sub-architectures for each Debian architecture. For i386 these would be mmx, sse, 3dnow, etc. For ppc we'd have altivec. Then update-subarch-alternatives would run at boot time and adjust links based on the available cpu features and available libraries. What this needs is a format to store the list of available libraries and the sub-arches they support. For example, if you install libexample_0.1-1.deb this has no sub-arch support, so will be used by default. If you install the separate package libexample-vec_0.1-1.deb, this adds a new version to the list, and will be used if the CPU has altivec. - Adrian Cox, AG Electronics 1) Apart from /etc/mtab and /etc/motd. You can link /etc/mtab to /proc/mounts. You lose a little functionality, but nothing important. You can disable motd editing in /etc/default/rcS.
