On Mon, 2006-05-01 at 19:15, Stephen Hahn wrote: > Here's an updated version based on feedback. Comments by end of > tomorrow, California time, please.
I've been following this, and have serious reservations and a growing sense of unease. > PSARC/2006/xxx > /usr/gnu > | Stephen Hahn (sch at sun.com) and Bart Smaalders (barts at eng.sun.com) > > 1. Summary > > | A new directory hierarchy, to contain otherwise-name-conflicting GNU > | utilities under their original names, is proposed. A guideline for > | the provision of 'g'-prefixed variants in /usr/bin is also > | presented. > > This case seeks Minor release binding. > > 2. Discussion > > In an attempt to provide a more complete offering for software > developers on OpenSolaris distributions (as well as other goals), What other goals? > this case proposes the introduction of /usr/gnu as a location for > | alternate implementations of standard tools produced by the GNU > | project. What's the definition of GNU software? I would presume software categorized by GNU as "Official GNU software". And are we talking about the complete set of tools on the official GNU list, or just a subset - and what determines the subset? What happens to other open source software? > This case supplements PSARC/2005/185, "Enabling > | serendipitous discovery" [1]. The goals of the two cases are > | aligned; this case may propose refinements to the handling of > | specific scenarios. > > 2.1. Expected use > > | Much like the use of the XPG4 [2] and XPG6 [3] environments, the > | expected use of the /usr/gnu environment is to prefer its > binary components to the system defaults, via a setting like > > PATH=/usr/gnu/bin:...:/usr/bin > > | Traditionally, the commands environments are incomplete: they do > | not provide entries for each and every command available in > | /usr/bin. The environments are also proper subsets: there are no > | commands that are not also present in the system's default command > | environment. Although an environment could be modified to be a full > | alternative commands environment, that aspect is left to a future > | discussion. I think /usr/gnu *should* be a full and complete alternative environment. The thing's supposed to be self-contained, at any rate: I would expect that having /usr/gnu/bin in my PATH but not /usr/bin would result in a fully functional GNU environment. I don't see that the analogy with xpg4 and xpg6 is a good one. > 2.2. Reliance on /usr/gnu/bin utilities > > The individual utilities' stability levels dictate their > appropriateness for use by other components. > > | 2.3. Utility parity requirements > | > | PSARC, in its opinion for PSARC/2005/683 [4 - 5], made policy a > | technical requirement that XPG4 and XPG6 extensions be also made > | available in the /usr/bin variant of the affected utility. This > | policy is not applicable to the /usr/gnu environment. > | > | 2.4. 'g' Prefixing > > Historically, introduction of GNU utilities into /usr/bin has been > done with a 'g' character prefixed to the utility name. This > proposal amends this practice: the 'g'-prefixed version should be > provided if already introduced. In cases where another operating > system has provided a 'g'-prefixed version, the project team > | introducing an otherwise name-conflicting GNU component may choose > | to also provide one; otherwise, additional 'g'-prefixed components > | in /usr/bin are discouraged. > > | GNU components that do not conflict with existing or anticipated > | components in the system's default commands environment should not > | be placed in /usr/gnu, and do not require 'g'-prefixing. I disagree with this, strongly. For the first thing, GNU components should be placed under /usr/gnu for consistency - if GNU foo is in /usr/gnu/bin, I would expect GNU bar to be there too. What's being proposed ends up with commands being randomly located based solely on the arbitrary sequence of characters in their name rather than on any technical basis. Another problem I have with this is that if I need to override a utility (for example, if I need to use a utility from blastwave) then I would be forced to place the alternative tools location ahead of /usr/bin, therefore overriding (potentially) the whole Solaris toolset rather than just the pesky GNU commands I needed to. This also elevates GNU to a privileged position - what if some other toolset (BSD, for example) were to be integrated? In other words, GNU software should *all* go into /usr/gnu, with presence in /usr/bin (or wherever) being determined individually. Ultimately, I am unclear as to the precise goals of this proposal. A simple "provide the entire GNU toolset under /usr/gnu" proposal is something I can understand and support, and could be a valid part of meeting other goals. (Or even, "provide a well-defined subset of all GNU software under /usr/gnu".) On my previous system I provided /usr/local/gnu for essentially the same purpose. What we discovered was that this created enough problems when hidden at the end of the path, and total chaos when at the start of the path; enough so that we rapidly went back to a fairly minimal exposure of the GNU utilities in the default path (and with a g prefix). General user behaviour suffered if it was early in the path - we had a lot of old scripts break (some because they expected ucb behavior); problems arose when building software (I can't remember the details, but something along the lines of version mismatches between the autotools we had and that used to develop the software we were trying to build - but this was some time ago when the autotools were evolving rapidly and may not be the case today). -- -Peter Tribble L.I.S., University of Hertfordshire - http://www.herts.ac.uk/ http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
