Stephen Hahn writes:
> > I think this needs clarification: consider a GNU package like coreutils
> > which has both components which conflict with their /usr/bin counterparts
> > (like ls) and those that don't exist in /usr/bin (or anywhere else, like
> > seq) and thus don't conflict. I cannot believe that the proposal is to
> > introduce the non-conflicting tools into /usr/bin, and leave the rest of
> > the package in /usr/gnu/bin. Apart from being a maintenance nightmare (the
> > GNU packages just don't provide the infrastructure to install different
> > binaries into different bindirs), it takes away the possiblity to run in a
> > pure Solaris (i.e. non-GNU) environment (where seq doesn't exist).
>
> It is unfortunately proposing just that. Your following scenarios are
> all correct (including the identification that a completely separate
> GNU-only environment is not possible).
>
> I was talked out of having the /usr/bin:/usr/gnu/bin ordering
> ("fallback to GNU") a couple of days ago--mostly to stay consistent
> with "serendipitous discovery". At this point, I don't see how to
It may be just a language barrier, but could this ARC case be posted
somehere? I don't have a clear idea what it is really about, which makes
discussion difficult ;-)
> reconcile the two cases simultaneously. Making /usr/gnu a
> self-consistent tree is substantially easier for the integrator.
Exactly. Installation a GNU package partially into /usr/gnu and partially
into /usr is just asking for trouble and may well mean that it takes (much)
longer to integrate new versions.
Rainer
