Re: developer release 3.1.2
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.
Reply to: