> James C. McPherson wrote:
> > frank wang wrote:
> >> Sun will keep two universes, 1 is "Linux" alike,
> >> the other "Solaris" alike. User can just pick what
> >> they like or are familiar with. But it
> >> can't replace the efforts to scale the train
> >> coverage on everyting about
> >> Solaris/UNIX.will" ??? I doubt it.
>
> Frank, I think you are mis-reading /
> mis-understanding the psarc /usr/gnu case.
>
> Simply put:
>
> if we don't have a conflict in functionality, dump
> the gnu version in /usr/bin
apologies to jcmp, who just managed to catch me when I've
been contemplating these issues for the last several months
and I feel the need to speak out.
This is *not* directed at him.
------------------
This is so braindead, it makes me want to scream. Solaris is
how old now? I've been porting code to Solaris for 14 years
now (since Solaris 2.3 on Sparc). In all that time, I've had to
learn how to work around building the code correctly on
Solaris, so I'm not lugging around LD_LIBRARY_PATH, or use
the GNU tools in their own directory without a "g" prefix
prepended to my path so the configure scripts have a better
chance of working out of the box (excepting linker behavior
which has rarely, if ever not needed fixing if someone hasn't
been actively maintaining the code in a Solaris environment,
or dealing with specific gcc'isms).
What, do we really think that magically we're going to put all
these commands in /usr/bin and all of a sudden, a shedload
more Open Source software will *just* compile on Solaris.
This just goes to show that folks making the decision aren't
involved actively in porting any Open Source software to
Solaris, because otherwise they would understand that in
many cases, it's not just the tools, but the naming of the
tools, not to mention specific Solaris behaviors as it relates
to includes and libraries and those differences to other
*nix-like systems.
> if we do have a conflict, create /usr/bin/g[blah] as
> a symlink to /usr/gnu/bin/[blah]
So this isn't any different that having said tool in /usr/sfw/bin.
And it also assumes that users are way too stupid to be able
to use a PATH variable effectively. Course, it would help if
there was a locate command on Solaris, and some effective
HTML documentation detailling out all the tools that exist
on the Solaris install (since every argument I've heard about
doing this relies on the issue that users can't find the tools)
It still requires Open Source software to either be conscious of
GNU'ish tools having a g-prefix, or the user being smart enough
to tell the configure script to use said tool (and the tool even
being able to deal with a g-prefixed command) This is not going
to make the user experience any better, and is more likely to
further confuse users and non-Solaris ready Open Source
packages.
> Now, as to what Ian is proposing - we'll have to wait
> and see. I've heard that he had a really really hectic time at
> JavaOne so it could be a little while.
I have to wonder what Sun/Ian are really trying to acomplish. It feels
an awful lot like a publicity ploy. Personally, I *like* the flavor of
Solaris. I've been using it a long time. Diluting Solaris to be more
Linux like, is different from giving Solaris a more Linux like profile.
Can you understand the difference?
Is the expectation that they throw all the gnu software into solaris and it
becomes a magic panacea that makes building open source software
easier?
All this is going to do is further confuse the issue on Solaris
WRT buildling open source software.
IMO, a more sane infrastructure would be to do the following:
1) keep GNU software in /usr/gnu with g prefixes, with the exception of
the exiting GNU software already in /usr/bin (bash, less, etc)
2) create a set of symlinks in /usr/gbin translating the g-prefixed tools
in /usr/gnu/bin to normal non-g-prefixed tools, such that putting
/usr/gbin in front of /usr/bin makes Solaris look more like a native
Gnu-*nix system.
If you want a Solaris only, native system, you have a PATH that has
/usr/bin without /usr/gnu/bin. More and more, there is very little
open source code that would actually fall into that category.
If you want a Solaris with Gnu behaviors, you have
/usr/bin followed by /usr/gnu/bin (much like /usr/bin:/usr/sfw/bin today).
Again, unless Open Source code is aware of g-prefixed commands
or can be instructed via enviornment variables (like env SED=gsed
./configure....)
configure typcially doesn't always get everything it can.
If you want a Solaris Gnu-ish system, then you would have
/usr/gbin followed by /usr/bin. Today, only folks who have made
a concerted effort to do something like this will have this functionality.
The benefit of this is that the typical problems on Solaris systems with
borkened tools like sed, awk, make, grep and so on, are going to
be typically bypassed.
However, all this will really serve is to make some open source software build
a little easier out of the box, but will continue to let folks just assume that
the software builds correctly. Again, I must reiterate that most open source
software does not build properly on Solaris because it fails to pass the proper
linker flags through the system to be built. Things like LD_OPTIONS, again,
*require* the user to know alot about the open source package and which
libraries it requires, or we end up having folks who lug around an LD_OPTIONS
always, and then we end up having to answer the other half of the users who
don't user an LD_OPTIONS variable.
I'm surprised that Sun hasn't started some sort of open source archive dedicated
to really porting open source packages to Solaris, instead of having a bunch of
hacks driven by makefiles and distributed by the CCD or SFW. Every single
archive
so far, with maybe the exception of pkgsrc, hasn't had any *real* usable
visibility
into the configuration of the packages, especially WRT to changes, patches,
configure time parameters and the like)
The place where I think Sun/Ian wants to be is to have Open Source software
be able to work by a user be able to say "./configure --prefix=/opt/mydir"
without having to
1) set an LD_OPTIONS or LD_LIBRARY_PATH, or other compile type environment
variable beyond CC and CXX. (configure should be able to find includes and
libraries/library paths on Solaris automagically)
2) have to set options where to find libiconv, X11, opengl, sound, etc, ie
any package that the open source package has as a dependency.
3) have to fiddle with PATH's to get commands that have specific behaviors
(like needing GNU {grep,diff,make,patch,awk,bash} )
4) figure out which compiler (gcc-3.4.x, gcc-4.x, studio compilers)
and set of compiler options need to be set
5) have a huge amount of Solaris knowledge on how to make said
packge compile without spending hours or days doing it.
And just lugging around a badly thought out idea of bringing in GNU'ish
code arbitrarily into Solaris without understanding what this is going to
do to the current state of development of Open Source code on Solaris
is just indicative of how the powers-that-be "understand" the Open
Source issue. If anyone wants to think that Solaris is really on the
cutting edge, all you have to do is look in /etc/skel for the "start scripts"
and see a path variable is probably hasn't changed in 15 years....
This message posted from opensolaris.org
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
