On Wed, 31 Jan 2007 11:40:19 -0800 Danek Duvall wrote:
> How do you envision the same issues playing out in /usr/lib?
> Do we force developers who want their apps to link to a consistent set of
> libraries from one machine to the next to use -R/usr/sun/lib?
> One thing we've found over the years
Kyle McDonald writes:
> At least not until these packages stop using compile-time options. Sun
> can ship uptodate versions, but unless they are also going to ship every
> permutation of compile time options, it won't work.
>
> Also sites don't like to move to a new version till they do so on ev
James Carlson wrote:
> Kyle McDonald writes:
>
>>> You're missing at least two downsides that've already been discussed:
>>>
>>> - The behavior of the system for ordinary users depends on whether
>>> the administrator has installed this special package. Thus, users
>>> are (at least t
Laszlo (Laca) Peter writes:
> It seems that most common concern with installing the FSF/GNU binaries
> in /usr/bin is that they will become obsolete and [some] users/admins
> want to use their own, newer versions instead, which they can only do
> through link farms or aliases.
>
> I think this is
Kyle McDonald writes:
> > You're missing at least two downsides that've already been discussed:
> >
> > - The behavior of the system for ordinary users depends on whether
> > the administrator has installed this special package. Thus, users
> > are (at least to some degree) beholden to a
Laszlo (Laca) Peter wrote:
> It seems that most common concern with installing the FSF/GNU binaries
> in /usr/bin is that they will become obsolete and [some] users/admins
> want to use their own, newer versions instead, which they can only do
> through link farms or aliases.
>
> I think this is a
James Carlson wrote:
> Kyle McDonald writes:
>
>> The Symlink package, fixes all of this. utilities will be at a known, OS
>> controlled location for other packages to depend on, Can be found in
>> /usr/bin on systems where that is desirable, and can be overridden by
>> admins and/or users wh
It seems that most common concern with installing the FSF/GNU binaries
in /usr/bin is that they will become obsolete and [some] users/admins
want to use their own, newer versions instead, which they can only do
through link farms or aliases.
I think this is a valid concern, but not an architectura
Stephen Hahn wrote:
> * James Carlson [2007-01-30 13:55]:
>
>> Stephen Hahn writes:
>>
>>> * James Carlson [2007-01-30 12:03]:
>>>
Stephen Hahn writes:
> (In John's example, star poses no conflict
>
Actually, it does. I don't necessaril
Kyle McDonald writes:
> The Symlink package, fixes all of this. utilities will be at a known, OS
> controlled location for other packages to depend on, Can be found in
> /usr/bin on systems where that is desirable, and can be overridden by
> admins and/or users who know and want to.
>
> It seem
Richard L. Hamilton wrote:
> Ok, fine. Then throw whatever non-conflicting commands you like
> into /usr/bin and call it serendipitous discovery.
>
> But also create a /usr/sun or whatever and populate it with
> symlinks only to commands that don't come from external open source
I'd go one step f
Nicolas Williams wrote:
> On Tue, Jan 30, 2007 at 12:04:35PM -0800, John Plocher wrote:
>
>> The disconnect here is semantic:
>>
>> Before this proposal, it was possible to construct a PATH that provided
>>
>> Solaris/Posix/SUS utilities first,
>> "latest and greatest" GNU utilities
On Wed, Jan 31, 2007 at 11:57:06AM -0500, Kyle McDonald wrote:
> Put GNU in /usr/gnu
> Move the Solaris environment (The things from /usr/bin that you describe) to
> /usr/sun.
>
> Then softlink both back into /usr/bin.
We've been talking a lot about /usr/bin.
How do you envision the same issu
* James Carlson [2007-01-31 09:01]:
> Kyle McDonald writes:
> > The Symlink package, fixes all of this. utilities will be at a known, OS
> > controlled location for other packages to depend on, Can be found in
> > /usr/bin on systems where that is desirable, and can be overridden by
> > admins
Joerg Schilling writes:
> > In the 'schilly' universe, unadorned 'tar' is star.
>
> I don't know what you understand by "unadorned 'tar'"...
It means "when the user types just 'tar' and relies on his $PATH to
find the right one" -- that is, unadorned by any explicit path.
> Star behaves differen
James Carlson wrote:
> Stephen Hahn writes:
> > * James Carlson [2007-01-30 12:03]:
> > > Stephen Hahn writes:
> > > > (In John's example, star poses no conflict
> > >
> > > Actually, it does. I don't necessarily agree with him, but Joerg has
> > > good reason to want 'star' to be /usr/bin/t
On Tue, Jan 30, 2007 at 05:29:16PM -0800, Richard L. Hamilton wrote:
> Ok, fine. Then throw whatever non-conflicting commands you like
> into /usr/bin and call it serendipitous discovery.
>
> But also create a /usr/sun or whatever and populate it with
> symlinks only to commands that don't come f
> On Tue, Jan 30, 2007 at 05:29:16PM -0800, Richard L.
> Hamilton wrote:
> > Ok, fine. Then throw whatever non-conflicting
> commands you like
> > into /usr/bin and call it serendipitous discovery.
> >
> > But also create a /usr/sun or whatever and populate
> it with
> > symlinks only to commands
Ok, fine. Then throw whatever non-conflicting commands you like
into /usr/bin and call it serendipitous discovery.
But also create a /usr/sun or whatever and populate it with
symlinks only to commands that don't come from external open source (or
have historically diverged significantly from them
Stephen Hahn writes:
> * James Carlson [2007-01-30 12:03]:
> > Stephen Hahn writes:
> > > (In John's example, star poses no conflict
> >
> > Actually, it does. I don't necessarily agree with him, but Joerg has
> > good reason to want 'star' to be /usr/bin/tar.
>
> In the interests of having
Stephen Hahn writes:
> (In John's example, star poses no conflict
Actually, it does. I don't necessarily agree with him, but Joerg has
good reason to want 'star' to be /usr/bin/tar.
> and the /opt/csw variants
> are already using the PATH mechanism to resolve conflicts, so I'm not
> sure w
On Tue, Jan 30, 2007 at 12:04:35PM -0800, John Plocher wrote:
> The disconnect here is semantic:
>
> Before this proposal, it was possible to construct a PATH that provided
>
> Solaris/Posix/SUS utilities first,
> "latest and greatest" GNU utilities second.
>
> After this proposal,
John Plocher writes:
> Potential Answer: I should stop using the CSW generated gnu
> bits in favor of building and using the latest
> SFW gnu packages. This presumes that this
> OpenSolaris/GNU project keeps those bits u
* James Carlson [2007-01-30 13:55]:
> Stephen Hahn writes:
> > * James Carlson [2007-01-30 12:03]:
> > > Stephen Hahn writes:
> > > > (In John's example, star poses no conflict
> > >
> > > Actually, it does. I don't necessarily agree with him, but Joerg has
> > > good reason to want 'star' to
On Tue, Jan 30, 2007 at 11:48:29AM -0800, John Plocher wrote:
> Nicolas Williams wrote:
> >On Tue, Jan 30, 2007 at 10:38:29AM -0800, John Plocher wrote:
> >>A) A problem with comparing XPG4 with the gnu stuff is that the
>
> >This seems irrelevant, particularly in light of serendipitous discovery.
* James Carlson [2007-01-30 12:03]:
> Stephen Hahn writes:
> > (In John's example, star poses no conflict
>
> Actually, it does. I don't necessarily agree with him, but Joerg has
> good reason to want 'star' to be /usr/bin/tar.
In the interests of having a finite discussion, I must point ou
On Tue, Jan 30, 2007 at 10:38:29AM -0800, John Plocher wrote:
> C) Another problem is that of what actually ends up in /usr/bin. This
> propoal
>makes it "first come, first serve" - put it into /usr/bin as long as
>you are the first one there, otherwise put it in a different place. This
On Tue, Jan 30, 2007 at 10:38:29AM -0800, John Plocher wrote:
> B) How does this address the issue of "the bits delivered by Sun
>are stale and I'd like to refresh them?" Because the OpenSolaris
>/usr/bin/gnu project isn't the primary developer/publisher of
>these bits, it can not clai
On Tue, Jan 30, 2007 at 10:38:29AM -0800, John Plocher wrote:
> Bart Smaalders wrote:
> >OpenSolaris supports multiple command environments, but it does
> >so through placing alternate versions of commands found in /usr/bin
> >ahead in the user's path.
>
> I want the gnu bits to be usable on Sola
Nicolas Williams wrote:
> On Tue, Jan 30, 2007 at 10:38:29AM -0800, John Plocher wrote:
>> B) How does this address the issue of "the bits delivered by Sun
>>are stale and I'd like to refresh them?"
> The easy way to deal with this is this:
>
> - the OpenSolaris community (including ARCs) i
* James Carlson [2007-01-30 11:23]:
> John Plocher writes:
> > At some future point, we may have: Posix ls got there first,
> > along with AT&T's make and Joerg's star. This means that the
> > gnu ls, csw's ls, make and star and the three or four other
> > versions of make all are
Nicolas Williams wrote:
> On Tue, Jan 30, 2007 at 10:38:29AM -0800, John Plocher wrote:
>> A) A problem with comparing XPG4 with the gnu stuff is that the
> This seems irrelevant, particularly in light of serendipitous discovery.
My point was not "interface stability" - it was "freshness of bits"
Bart Smaalders wrote:
> OpenSolaris supports multiple command environments, but it does
> so through placing alternate versions of commands found in /usr/bin
> ahead in the user's path.
I want the gnu bits to be usable on Solaris as well, but I am concerned
that this proposal will have unintentio
Richard L. Hamilton wrote:
> Why not avoid the problem by putting all the FSF stuff in /usr/gnu,
> and having an optional package of symlinks in /usr/bin which no other
> package with dependencies on the /usr/gnu stuff should require? That way,
> users could choose whether to have non-conflicting
[...]
> -1This proposal puts a set of OSS utilities in
> /usr/bin where
> they become intermingled with core Solaris commands.
> . It also
> puts conflicting commands in /usr/gnu. This lets the
> e user
> choose between
> Solaris versions 1st + Solaris-GNU versions 2nd
>
I've added three issues of my own to the bottom; sch-0 is the "why
are you doing this?" issue.
- Stephen
jdc-1 The proposal selects /usr/gnu as FSF/UNESCO Free Software, but
why is this the important or useful determinant? More to the
point: what software or use
36 matches
Mail list logo
