James Carlson wrote:
> ...
>
>> Marcel makes a good point, that software could be added to that list
>> later. In such cases, the conflicting components may have been given
>> a new location; however, it is incorrect to assume that those
>> components ended up in /usr/sfw. (As, at the time of ARC proposal,
>> the name conflict would have had to have been dealt with.)
>>
>>
>
>So, if they don't go in /usr/sfw (because we're trying to burn that
>house down), and they can't go in /usr/bin (because they conflict),
>and they can't go in /usr/gnu (because they're not on the special
>list), then we _are_ necessarily setting precident that future open
>source projects will need to create new paths.
>
>That seems unfortunate. We'll end up back in the state where things
>that Linux users, to whom I think we're bowing here, expect to be in
>/usr/bin may instead be scattered about the system.
>
>
Can we formalise the use/presence of /usr/local to be the basket
for all of the /usr/sfw and /usr/gnu things to fall into? In the very
least, it is a familiar name.
Or does this remain the domain of local administration?
The model used by {Free,Net}BSD is their equivalent to our
"ON" goes in /bin, /usr/bin, /sbin, /usr/sbin, /usr/libexec with
a single destination for binaries that don't want to live in that
tree: /usr/ports or /usr/pkg. I've never seen anyone come up
with a "we need a GNU environment" model.
Darren
p.s. http://www.pl.netbsd.org/Documentation/pkgsrc/platforms.html
