Re: [osol-discuss] Re: [gnu-sol-discuss] Incorporating open-source cmds/libs into OpenSolaris
Darren J Moffat [EMAIL PROTECTED] wrote: On Thu, 2005-12-01 at 11:30, Joerg Schilling wrote: If you take this seriously, then ZFS could not have been allowed to be released the way it has been, because SVN_27 introduces incompatible changes in the ACL interface that would have to be addressed before note that these incompatible changes cause problems in star. I disagree with you here and so did the ARC that this is an incompatible change. It is a set of ACLS for NFSv4 and ZFS filesystems with a compatible change to the existing system call - ie binaries still worked as they did before they just can't backup the new ACLs. This just wasn't possible the new ACLs have information in them that you just couldn't express with the old ones; plus they are what customers want and need and backup and archiver software will just have to change or become irrelevant. If you run star -c -dump -acl on a ZFS tree you should find out your self that there indeed was an incompatible change... well, you could call it a bug. But why does acl(info-f_name, GETACLCNT, 0, NULL) sometimes return an error code that is not listed in the Solaris 10 man pages with either code or reason? Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED](work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: [gnu-sol-discuss] Incorporating open-source cmds/libs into OpenSolaris
[EMAIL PROTECTED] wrote: It's kinda hard to mistype gnome-short-command-names-are-so-not-practical as zpool destroy ... too. You may be right with those short commands, but how about the longer commands with 2 or 3 chars that are similar to frequently typed program names? In any way: I don't like the GUI commends to be in /usr/bin/ Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED](work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: [gnu-sol-discuss] Incorporating open-source cmds/libs into OpenSolaris
On Thu, 2005-12-01 at 11:30, Joerg Schilling wrote: If you take this seriously, then ZFS could not have been allowed to be released the way it has been, because SVN_27 introduces incompatible changes in the ACL interface that would have to be addressed before note that these incompatible changes cause problems in star. I disagree with you here and so did the ARC that this is an incompatible change. It is a set of ACLS for NFSv4 and ZFS filesystems with a compatible change to the existing system call - ie binaries still worked as they did before they just can't backup the new ACLs. This just wasn't possible the new ACLs have information in them that you just couldn't express with the old ones; plus they are what customers want and need and backup and archiver software will just have to change or become irrelevant. Veritas and Legato have the same choice to make for their backup software that you have for your archiver, I'm pretty sure they will just make the change. -- Darren J Moffat ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: [gnu-sol-discuss] Incorporating open-source cmds/libs into OpenSolaris
On Tue, 29 Nov 2005, Bryan Cantrill wrote: but we know from painful experience that acts of cowardice like /usr/proc/bin create more problems than they solve. Curious, what problems other than $PATH would those be? The shell PATH issues at least can easily be dealt with with some intelligent system profiles (e.g. see /etc/profile.d/ on some linux systems). It's not too difficult to splice an appropriate PATH together based on what is installed to make things easy for users, it's impossible to split super-directories though. So there must be more to it than just $PATH? --paulj ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: [gnu-sol-discuss] Incorporating open-source cmds/libs into OpenSolaris
Alan DuBoff [EMAIL PROTECTED] wrote: As other tars just do not have enough features, I guess that you call star anyway. But for scripts it is of course needed to have a conforming tar in the PATH. Conforming means that the program called under the name tar must not cause unexpected problems. This includes creating archives that cannot be unpacked by a standard tar. You miss the point entirely. This is not about which tar has the best I don't beieve so... features. The tar that is in the core systems should be the tar that I use, which has all the latest features, plus supports any legacy support (for POSIX for instance), and in general just works. It should have the features of star in it, as well as gtar, or Sun tar. First, POSIX currently does not longer contain tar. And if you install star as /usr/bin/tar, you get 99.99% compatibility with Sun's tar and 100% compatibility with the latest POSIX that did include tar. If you like the features from other tar implementation from a program called 'tar' you will get into trouble as this is not really possible with a program that uses a legacy CLI from the 1970s. This is why I always call star because I like the features. If you don't believe, please tell me whether you believe that a command line like: tar cf archive -find . ( -type d -chmod u=rwx,go=rx -o true ) -chown root -chgrp root could be called compatible with what users of the command tar expect. With star, this is no problem and has been integrated recently. I want folks to work on the one common tar that works for everyone. It's located at /usr/bin/tar. If you don't depend on too extreme Sun specific extensions, you could do this by installing star as /usr/bin/tar. Star could even implement 100% Sun tar compatibility, but it becomes harder if Sun introduces unusable archive format extensions as e.g. done with ZFS ACL support. In the current state, I think you would agree we have too many efforts. OpenSolaris really needs to streamline these efforts together somehow, so that everyone can focus on the real problems rather than the same problems. I agree, but note that there was already an attempt to replace Sun tar by star earlier. In this case, your ideas would apply: Sun would have at least a need to discuss archive format extensions for usability before introducing them. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED](work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: [gnu-sol-discuss] Incorporating open-source cmds/libs into OpenSolaris
On Thursday 01 December 2005 03:30 am, Joerg Schilling wrote: In former times, it was usual to (by intention) have a limited PATH for root in order to reduce provlems by miss-typed commands and similar. Let's try to forget about the past, and let's try to look towards the future. We also had small volumes on many disks as well. If you add all binaries to a single directory, this will no longer work. I don't think it's that bad yet. I think there's still a lot of life to the core system, for the forseeable future anyway. But what do I know?:-/ It's kinda hard to mistype gnome-short-command-names-are-so-not-practical as zpool destroy ... too. Casper ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: [gnu-sol-discuss] Incorporating open-source cmds/libs into OpenSolaris
On Thursday 01 December 2005 05:33 am, Joerg Schilling wrote: First, POSIX currently does not longer contain tar. And if you install star as /usr/bin/tar, you get 99.99% compatibility with Sun's tar and 100% compatibility with the latest POSIX that did include tar. That's fine. wether the future version starts life as star, gtar, futar, or tar, doesn't matter. If you like the features from other tar implementation from a program called 'tar' you will get into trouble as this is not really possible with a program that uses a legacy CLI from the 1970s. This is why I always call star because I like the features. This is just one example, any program on the system could be the same. If you don't believe, please tell me whether you believe that a command line like: Again, each program is similar. tar, in this example, needs to come up with a single version that is in OpenSolaris and moves forward. If you don't depend on too extreme Sun specific extensions, you could do this by installing star as /usr/bin/tar. Star could even implement 100% Sun tar compatibility, but it becomes harder if Sun introduces unusable archive format extensions as e.g. done with ZFS ACL support. The community and CAB should decide how this moves forward and how the communtity works with Sun, as Sun does with the community. In the current state, I think you would agree we have too many efforts. OpenSolaris really needs to streamline these efforts together somehow, so that everyone can focus on the real problems rather than the same problems. I agree, but note that there was already an attempt to replace Sun tar by star earlier. In this case, your ideas would apply: Sun would have at least a need to discuss archive format extensions for usability before introducing them. Again, tar is just one example of a program which already has multiple binaries floating around and something people expect to be on the system. -- Alan DuBoff - Sun Microsystems Solaris x86 Engineering ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: [gnu-sol-discuss] Incorporating open-source cmds/libs into OpenSolaris
PJ == Paul Jakma [EMAIL PROTECTED] writes: PJ On Tue, 29 Nov 2005, Bryan Cantrill wrote: but we know from painful experience that acts of cowardice like /usr/proc/bin create more problems than they solve. PJ Curious, what problems other than $PATH would those be? Nobody finds them, because they're out of the way. It's also an annoyance for administrators, because they have to add yet another directory to their PATH. Much better to put the new feature right in their path, so to speak, than to make them have to take positive action just to find it. PJ The shell PATH issues at least can easily be dealt with with some PJ intelligent system profiles (e.g. see /etc/profile.d/ on some linux PJ systems). PJ It's not too difficult to splice an appropriate PATH together based on PJ what is installed to make things easy for users, it's impossible to PJ split super-directories though. PJ So there must be more to it than just $PATH? Matt -- Matt Simmons - [EMAIL PROTECTED] | Solaris Kernel - New York Every one already knows the definition of a 'good' landing is one from which you can walk away. But very few know the definition of a 'great landing.' It's one after which you can use the airplane another time. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: [gnu-sol-discuss] Incorporating open-source cmds/libs into OpenSolaris
On Thu, 1 Dec 2005, Matthew Simmons wrote:
Nobody finds them, because they're out of the way.
It's also an annoyance for administrators, because they have to add
yet another directory to their PATH.
Much better to put the new feature right in their path, so to speak,
than to make them have to take positive action just to find it.
Why can't this be done with an appropriate /etc/profile?
It's fairly easy to supply a system profile for both sh and csh to read
in files from, e.g., /etc/profile.d/. If you install a package that
creates, say, /usr/foo/bin/, that same package could also drop a file
into /etc/profile.d/, say 'foo.sh' to do:
PATH=${PATH}:/usr/foo/bin
(And potentially any other environment setup this 'foo' package needs).
It can also supply a /etc/profile.d/foo.csh for csh users.
That way you get the best of both worlds. Logically seperated sets of
binary directories + all commands available to the user in PATH. Unusual
users can just set their own PATH if they wish. (Or you can take it
further and have profile.d/foo.sh's PATH setting be conditional on the
user /not/ having set FOO_EXCLUDE_PATH in their ~/.profile).
We have the technology :)
--paulj
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: [gnu-sol-discuss] Incorporating open-source cmds/libs into OpenSolaris
PJ == Paul Jakma [EMAIL PROTECTED] writes: PJ On Thu, 1 Dec 2005, Matthew Simmons wrote: Nobody finds them, because they're out of the way. It's also an annoyance for administrators, because they have to add yet another directory to their PATH. Much better to put the new feature right in their path, so to speak, than to make them have to take positive action just to find it. PJ Why can't this be done with an appropriate /etc/profile? It could be done in any one of a thousand ways. I'm not going to argue the merits of each. I'm merely explaining why people didn't like /usr/proc/bin, and why we ended up folding it all back into /usr/bin. Matt -- Matt Simmons - [EMAIL PROTECTED] | Solaris Kernel - New York The Fifteen Commandments of Operational Security, Number 11: Thou shalt not drape thy net on thy tent, for it looketh like tent in net. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: [gnu-sol-discuss] Incorporating open-source cmds/libs into OpenSolaris
Bart Smaalders [EMAIL PROTECTED] wrote: My reason for preferring /usr/bin unless there's a name conflict is simply this : if users cannot readily find a command, they implicitly assume it isn't available. There is basically no benefit obtained from hiding commands in strange places around the system; once a user discovers he needs /usr/wombat/bin once in his path, he adds it - and any benefit obtained from sequestering commands there is immediately obviated. The reason why I still have objections against this idea is that you may like to create a PATH that includes less binaries and thus seems to me less dabgerous for administrators. Note that executables not normally used from the command line (Xorg, for example) should _not_ appear in the default path. This is where I definitely concur! Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED](work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: [gnu-sol-discuss] Incorporating open-source cmds/libs into OpenSolaris
On Wed, 2005-11-30 at 13:41, Joerg Schilling wrote: Bart Smaalders [EMAIL PROTECTED] wrote: My reason for preferring /usr/bin unless there's a name conflict is simply this : if users cannot readily find a command, they implicitly assume it isn't available. There is basically no benefit obtained from hiding commands in strange places around the system; once a user discovers he needs /usr/wombat/bin once in his path, he adds it - and any benefit obtained from sequestering commands there is immediately obviated. The reason why I still have objections against this idea is that you may like to create a PATH that includes less binaries and thus seems to me less dabgerous for administrators. I'd also like that but unfortunately for the Solaris product we crossed that line when GNOME was dumped into /usr/bin in the name of compatibility with some other platforms. In some cases the better administrator solution is using RBAC and having the admins run as them selves and use pfexec/pf*sh instead (only the things explicitly matched in /etc/exec_attr after a realpath() will run with privilege everything else runs as the normal use. If you want to be really paranoid use a role rather than direct profile assignment and don't allow the role to have the All profile which gives you full control over which commands can be run (including shell escapes by removing proc_exec from commands in the exec_attr entries). However I will be the first to admit this doesn't solve it for all cases and I really wish we hadn't dumped GNOME stuff in /usr/bin: 899 things in /usr/bin on my snv_27 system. However GNOME isn't really the biggest culprit there SUNWcsu alone drops 302 things into /usr/bin. -- Darren J Moffat ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [desktop-discuss] Re: [osol-discuss] Re: [gnu-sol-discuss] Incorporating open-source cmds/libs into OpenSolaris
On Wed, 2005-11-30 at 02:08, Alan Coopersmith wrote: Bryan Cantrill wrote: Suffice it to say that we have learned the hard way: put it in /usr/bin unless there's a conflict that prevents it. Though I still get complaints about GNOME being in /usr/bin, since it makes it harder to install another version and without breaking all the existing bits of the OS that depend on Sun's version. It depends on your definition of a conflict. My definition includes anything where you could have different versions of the same utility. What I would like is something like depot or stow, where I can have different versions (or different implementations of the same version) of software packages in their own private area. There is then some mechanism (could be as simple as add this directory to the PATH) to select a particular personality. You could have a link package that sets one of the versions as the default (so it appears in the default PATH). The throw everything in /usr/bin approach leads to a number of problems - the current situation with gnome being the prime example. It's hard to have multiple versions installed. Upgrading tends to break things. Because things are integrated it's harder to backport. Dependency hell is inevitable (because there's only one version, you have to upgrade the entire dependency tree in one go). As a system administrator, I'm after clean encapsulation with the ability to see exactly what's installed where, and the ability to upgrade, downgrade, and try new versions without interfering with the rest of the system. As a developer, I'm after having multiple versions of everything under the sun so I can test all the combinations. As a user, I want things to work and I don't want to care where they are. For the first two, shoving everything into one pot is definitely harmful; for the last one what's really needed is user profile management. -- -Peter Tribble L.I.S., University of Hertfordshire - http://www.herts.ac.uk/ http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: [gnu-sol-discuss] Incorporating open-source cmds/libs into OpenSolaris
On Wednesday 30 November 2005 05:41 am, Joerg Schilling wrote: The reason why I still have objections against this idea is that you may like to create a PATH that includes less binaries and thus seems to me less dabgerous for administrators. This type of situation is an exception, for distribution for instance. As a user I don't want more than one tar. I want one tar that works for me. And guess what? Yep, I want it named tar, not gtar, futar, star, etc...the command is tar and I would expect it to be in the core filesystem in most all cases (exceptions permitting). The question is how we get from where we are with multiples, to a point that we have an open version that is the most current, being worked on, in Solaris/OpenSolaris? That should be the goal of the community for all software in Solaris/OpenSolaris. Every piece of software should have the goal of being worked on as a community (i.e., both Sun and non-Sun folks), but that's not true at this time and will need time to workout. -- Alan DuBoff - Sun Microsystems Solaris x86 Engineering ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: [gnu-sol-discuss] Incorporating open-source cmds/libs into OpenSolaris
Paul Durrant [EMAIL PROTECTED] wrote: Initial Proposal * GNU commands that don't collide with current /usr/bin namespace - place these in /usr/bin. * GNU commands that do collide with commands already in /usr/bin - place these in /usr/gnu/bin, following the convention we started with /usr/xpg*/bin. I'd definitely go with this option. If there should be only one hierarchy for free software, it should not be named 'gnu' as GNU (FSF) programs are a minority in the FOSS universe. * Existing aliases (gtar, gmake, etc) will appear in /usr/sfw (and perhaps also in /usr/bin). You could add aliases to /usr/bin but I think it might be cleaner to keep GNU on non-GNU separated to avoid confusion. (Keeping symlinks from the current names in /usr/sfw to /usr/gnu is a good idea for backwards compatibility's sake though). If GNU tar is made available under the name 'tar' at all, it needs to be a recent version and compiled in a way that makes sure that the default archive format in create mode is POSIX compliant. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED](work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: [gnu-sol-discuss] Incorporating open-source cmds/libs into OpenSolaris
Nikhil wrote:
I believe all of them putting under /usr/gnu/{lib,bin,include} whatever
specific to gnu under /usr/gnu as prefix directory would be better.
Do you have a reason?
My reason for preferring /usr/bin unless there's a name conflict is
simply this : if users cannot readily find a command, they implicitly
assume it isn't available. There is basically no benefit obtained from
hiding commands in strange places around the system; once a user
discovers he needs /usr/wombat/bin once in his path, he adds it - and
any benefit obtained from sequestering commands there is immediately
obviated.
Since there's no useful benefit, why put users through this at all?
In Solaris for years, we placed commands that were subject to change
outside of Sun's control in /usr/sfw/bin. This led to such absurdities
as having a menu item on the Solaris desktop to launch Mozilla,
but having mozilla not be found when invoked from a shell with
the default path - and all of this ostensibly to protect the user!
We could add more and more directories to the default path, ala SUSE.
This seems somewhat broken, and is now problematic with so many users
already explicitly setting their paths rather than appending to the
one they inherit from their login shell.
Note that executables not normally used from the command line (Xorg,
for example) should _not_ appear in the default path.
- Bart
--
Bart Smaalders Solaris Kernel Performance
[EMAIL PROTECTED] http://blogs.sun.com/barts
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: [gnu-sol-discuss] Incorporating open-source cmds/libs into OpenSolaris
On Tue, Nov 29, 2005 at 11:22:52AM -0800, Bart Smaalders wrote:
Nikhil wrote:
I believe all of them putting under /usr/gnu/{lib,bin,include} whatever
specific to gnu under /usr/gnu as prefix directory would be better.
Do you have a reason?
My reason for preferring /usr/bin unless there's a name conflict is
simply this : if users cannot readily find a command, they implicitly
assume it isn't available. There is basically no benefit obtained from
hiding commands in strange places around the system; once a user
discovers he needs /usr/wombat/bin once in his path, he adds it - and
any benefit obtained from sequestering commands there is immediately
obviated.
Since there's no useful benefit, why put users through this at all?
In Solaris for years, we placed commands that were subject to change
outside of Sun's control in /usr/sfw/bin. This led to such absurdities
as having a menu item on the Solaris desktop to launch Mozilla,
but having mozilla not be found when invoked from a shell with
the default path - and all of this ostensibly to protect the user!
I'm just impressed that Bart was able to get through this rant without
quoting our favorite example of this: /usr/proc/bin. Indeed, this
directory was _so_ egregious that we put the p-tools in /usr/bin in
Solaris 8, leaving /usr/proc/bin as a directory of symlinks into /usr/bin.
Suffice it to say that we have learned the hard way: put it in /usr/bin
unless there's a conflict that prevents it. Yes, this sullies /usr/bin,
and yes, there is a non-zero risk in terms of system compatibility --
but we know from painful experience that acts of cowardice like
/usr/proc/bin create more problems than they solve.
- Bryan
--
Bryan Cantrill, Solaris Kernel Development. http://blogs.sun.com/bmc
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
Re: [desktop-discuss] Re: [osol-discuss] Re: [gnu-sol-discuss] Incorporating open-source cmds/libs into OpenSolaris
Bryan Cantrill wrote: Suffice it to say that we have learned the hard way: put it in /usr/bin unless there's a conflict that prevents it. Though I still get complaints about GNOME being in /usr/bin, since it makes it harder to install another version and without breaking all the existing bits of the OS that depend on Sun's version. -- -Alan Coopersmith- [EMAIL PROTECTED] Sun Microsystems, Inc. - X Window System Engineering ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [desktop-discuss] Re: [osol-discuss] Re: [gnu-sol-discuss] Incorporating open-source cmds/libs into OpenSolaris
On Tue, 2005-11-29 at 18:08 -0800, Alan Coopersmith wrote: Bryan Cantrill wrote: Suffice it to say that we have learned the hard way: put it in /usr/bin unless there's a conflict that prevents it. Though I still get complaints about GNOME being in /usr/bin, since it makes it harder to install another version and without breaking all the existing bits of the OS that depend on Sun's version. I see it like this: GNOME's /usr/bin stuff should correspond to the latest installed one and /usr/lib should has older libraries so, closed sourced user apps will not break. Erast ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [desktop-discuss] Re: [osol-discuss] Re: [gnu-sol-discuss] Incorporating open-source cmds/libs into OpenSolaris
Alan Coopersmith wrote: Bryan Cantrill wrote: Suffice it to say that we have learned the hard way: put it in /usr/bin unless there's a conflict that prevents it. Though I still get complaints about GNOME being in /usr/bin, since it makes it harder to install another version and without breaking all the existing bits of the OS that depend on Sun's version. Which I guess this opens the can of worms that is should the OS depend on its desktop? Ian ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: [gnu-sol-discuss] Incorporating open-source cmds/libs into OpenSolaris
I believe all of them putting under /usr/gnu/{lib,bin,include}
whatever specific to gnu under /usr/gnu as prefix directory would
be better.On 11/23/05, Eric Boutilier [EMAIL PROTECTED] wrote:
[ Followups: _Please_ post followups only to the GNU-Solaris community list:[EMAIL PROTECTED] ]Greetings,For disscussion purposes (comparing/contrasting), I put together this
post which contains the two leading proposals for name-spaceconventions of open-source commands and libraries in OpenSolaris. (Andby association, certain distros too I think:SchilliX, Blastwave/CSW,and Sun's Solaris and JDS).
--Eric=Sun Proposal, copied from http://opensolaris.org/os/community/gnu_solaris
=Date: Tue Jun 14, 2005Gnu SolarisThis community is all about incorporating/including GNU softwareinto OpenSolaris.
OpenSolaris supports lots of standards - XPG3, XPG4, XPG6, Posix,etc. GNU has become a defacto standard in the Linux and *BSDcommunities, and we've incorporated many GNU commands and librariesinto Solaris already, albeit often with name changes, marooned out in
/usr/sfw where new users cannot find it, etc.We would like to bring more GNU software into OpenSolaris, andrationalize the naming conventions without breaking backwardscompatibility. In addition, we could provide an individual user with
a choice of a GNU personality for OpenSolaris/Solaris.___Initial Proposal* GNU commands that don't collide with current /usr/bin namespace -
place these in /usr/bin.* GNU commands that do collide with commands already in /usr/bin -place these in /usr/gnu/bin, following the convention we startedwith /usr/xpg*/bin.* Existing aliases (gtar, gmake, etc) will appear in /usr/sfw (and
perhaps also in /usr/bin).___This naming proposal offers simple rules which would both simplifyaccess to GNU commands on an OpenSolaris-derived system, as well as
easily allow an individual user to have a GNU personality to theirdefault commands by placing /usr/gnu/bin first in their PATH.None of this is cast in stone; it's a idea to get people startedthinking about how to incorporate more open source software into
Solaris.===Schilling proposal, copied from:
http://mail.opensolaris.org/pipermail/opensolaris-discuss/2005-November/011157.html===Date: Tue Nov 15, 2005Alan Coopersmith
[EMAIL PROTECTED] wrote: Joerg Schilling wrote: - The current hierarchy on Sun Solaris is just using a planless aggregation of free software on various places. There is no reason
why GNOME related programs (that are completely useless without X that could modify the PATH) made it into /usr/bin while iportant programs like wget are hidden in /usr/sfw/bin/
There were plans - they just kept changing.8-) The plan for /usr/sfw/bin is changing to be mainly for things like GNU utilities whose names conflict with programs already in /usr/bin - those
that don't, like wget, are likely to move in the future. There's even talk of no longer hiding developer tools like make in /usr/ccs/bin!Yesterday, I had a long discussion about the best hierarchy
Here are my complusions that did lead me to my current decision:- Most free software is unique in functionality and name.This software may go either to /usr/bin or to /usr/sps/*or any other distribution specific FOSS hierarchy.
In case that a unique hierarchy name is desired, there is aneed to standardize on the way the programs are compiled.This means e.g. GNU tar (a secondary level application because
it creates a name clash if compiled in the default way) needsto be compiled to use the 'g' prefix and to create POSIX.1-1988compliant archives by default on all distributions that choose
to put GNU tar on the same location. If GNU tar is compiled to createnon-standard GNU-tar archives by default, there may be no linkwith the name 'tar' pointing to 'gtar'.- The following sources of free software create a significant number
of programs that do similar things than the POSIX basic tool setand thus create name clashes:*BSDthe
oldest source of tools (starting in 1978). As the currenttools
are significantly different from 4.2-BSD (/usr/ucb), itmakes
sense to reserve the /usr/bsd/* hierarchy in case thereis
a demand for porting recent versions of BSD tools.Schilymedium age (starting in 1982). The tools are currently in/opt/schily/*
but as they are not optional on SchilliX, itseems
that they belong to /usr/schily/* in future.GNU The youngest set of tools (starting around 1986).My
current idea is to put them into /usr/sps/* as Linuxusers
may expect them in the same hierarchy as the rest offree
software.
