Re: from / to /usr/: a summary
On Do, Dez 22, 2011 at 10:14:23 (CET), Philip Hands wrote:
> Could we not have a package that checks if a system is going to be
> unbootable under the circumstances in question (i.e. it has /usr on
> nfs4, or whatever) and refuse to install on such a system, lets call
> that package 'early-boot-usr'.
>
> Then for the people that are having to put in extra effort into
> packaging things that want to assume that /usr is there from early boot,
> they just need to depend on early-boot-usr.
Using a package "early-boot-usr" to describe a configuration decision
feels seems wrong. AFAIUI, you want to provide package maintainers an
interface to describe requirements how a system needs to be configured.
I can imagine a number of other use-cases where packages benefit from
declaring such feature constraints. Think of requirements on MMX, or
graphics hardware with proper 3d support and working drivers.
Introducing virtual or non-virtual packages for such constraints is
clearly not the best way to implement this. Maybe it's time to think
about integrating such constraint types into dpkg properly?
For this particular case, I think Debian would be better of with a
programmatic way in a core / essential package.
> I have a feeling that most of the people that care about the separation
> of / and /usr only really care on systems that don't need the packages
> that are going to have that dependency, and for the few overlaps that
> there are, the effort would then be focused where it's needed.
Can you provide examples of packages that can't work with both
configurations? It would be sad if this configuration choice, which is
impossible change without reinstalling the system, would restrict the
user what packages he can install.
--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4
Reply to: