[ 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-space conventions of open-source commands and libraries in OpenSolaris. (And by 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, 2005 Gnu Solaris This community is all about incorporating/including GNU software into OpenSolaris. OpenSolaris supports lots of standards - XPG3, XPG4, XPG6, Posix, etc. GNU has become a defacto standard in the Linux and *BSD communities, and we've incorporated many GNU commands and libraries into 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, and rationalize the naming conventions without breaking backwards compatibility. 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 started with /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 simplify access to GNU commands on an OpenSolaris-derived system, as well as easily allow an individual user to have a GNU personality to their default commands by placing /usr/gnu/bin first in their PATH. None of this is cast in stone; it's a idea to get people started thinking 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, 2005 Alan 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 a need 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) needs to be compiled to use the 'g' prefix and to create POSIX.1-1988 compliant archives by default on all distributions that choose to put GNU tar on the same location. If GNU tar is compiled to create non-standard GNU-tar archives by default, there may be no link with 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 set and thus create name clashes: *BSD the oldest source of tools (starting in 1978). As the current tools are significantly different from 4.2-BSD (/usr/ucb), it makes sense to reserve the /usr/bsd/* hierarchy in case there is a demand for porting recent versions of BSD tools. Schily medium age (starting in 1982). The tools are currently in /opt/schily/* but as they are not "optional" on SchilliX, it seems 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 Linux users may expect them in the same hierarchy as the rest of free software. It may be a good idea to create a second location (e.g. /usr/gnu/bin) with symlinks to /usr/sps/bin/<gnu-tool> to document the origin and to allow to use PATH to set up a specific precedence order. Here are my current plans for SchilliX (but I am open to discussions): - All important programs are in /usr/bin. This is to make it easy to select a minimal subset that is granted to be functional. bash, wget, smake all go here - Keep /usr/sfw as it is from Solaris ON - All programs with name clashes are put into different hierarchies and get a prefix character (e.g. 'g' for GNU tools). There are links to the generic name (e.t. 'tar' pointing to 'gtar') in order to allow to select GNU default behavior by putting /usr/sps/bin or /usr/gnu/bin before /usr/bin in the PATH. - Put all GNU tools and all unique tools into /usr/sps/* - Put all schily tools into /usr/schily/* - Put all BSD tools into /usr/bsd/* - It may make sense to have some symlinks for programs of medium importand in /usr/bin to e.g. /usr/schily/bin to allow people to use them without adding /usr/schily/bin/ into the PATH. Joerg -- 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
