[indiana-discuss] "no scripting zone" and isaexec(3C) == architectural

[Bob Doolittle]

Just to be clear - we're still talking about this *in addition to* 
retaining the existing /opt model for 3rd party (or unbundled) products 
which choose to use it, correct?

My issue with this model is that it doesn't account for existing 
products well. There are vendors out there in the world who already 
deliver to /opt on many platforms, who may not be interested in 
investing the effort to change their product to deliver into /usr since 
that might require them to change the names of their binaries to avoid 
naming collisions, plus issues of documentation and retraining of 
existing customers. If such a registry had existing since the beginning 
of time there would be few issues, but imposing it on an existing market 
can create problems for vendors and thus we should not force it.

-Bob

Nicolas Williams wrote:
> On Sat, Jun 06, 2009 at 02:05:29AM -0700, UNIX admin wrote:
>   
>>> Not necessarily.  A registry, for example, would
>>> allow us to solve that
>>> problem.
>>>       
>> Does such a solution exist as of now?
>>     
>
> Technically, yes.  Roughly: the ARC is the registrar and the product
> itself is the registry database.
>
> But you can see that that's not flexible enough to enable third-party
> delivery into /usr.  In order to allow that we'd need a bonafide
> namespace registry database, and we'd need registration rules tailored
> for a world in which third parties can deliver into /usr.
>
>   
>> Is it documented anywhere how to interface with it?
>>     
>
> Effectively, yes (see above, and filesystem(5)).
>
>   
>> Is it easy and convenient to use?
>>     
>
> Yes, it is, though in its current incarnation it doesn't support
> third-party regitrations (see above).
>
> More seriously...  Implementing a registry wouldn't be difficult, from a
> technical point of view (one of the myriad web front-ends to an open
> source DB would do, perhaps with a bit of DJango thrown in to make the
> UI prettier).  The crucial issues would be all political: a) community
> consensus for such a thing, b) funding to implement such a thing, and,
> finally, c) finding or creating, and funding, a body suitable to act as
> a registrar.
>
> I doubt Shawn's alone in wanting third-party software delivered into
> /usr.  It makes a lot of sense to me, for example.  Why should users
> have to manage their PATH at all?  To me the missing component is
> namespace management.
>
> I'm open too to the possibility that 3rd party software delivery into
> /usr is bad for other reasons I've not considered.  For one, even a
> registry couldn't prevent political conflicts over the namespace.  IIRC
> we've already seen conflicts between unrelated FOSS projects being
> fought over in OpenSolaris discuss lists (psarc-ext and
> opensolaris-arc).  But a popular namespace registry could actually help
> prevent such conflicts in the future, particularly if other distros were
> to use it.
>
> Nico
>