Joerg Schilling wrote: > Kyle McDonald <[EMAIL PROTECTED]> wrote: > > >> Not to mention that when Gnu tar was integrated, Solaris already had a >> 'tar' in /usr/bin. >> When 'compare' was integrated (by the first one to request it,) Solaris >> had nothing in /usr/bin/ named 'compare'. >> > > Could you please explain why some people including you try to "convert" > a general problem (that I mentioned some time ago) into a personal problem? > > I'm not making it personal. I don't see how you read that into what I wrote. I was just applying what I understand (now) the process to be to the example someone else asked about. > It seems that this is just to pretend it is less important than it really is. > > The general problem is that conflicting names cannot be in /usr/bin in order > to avoid problems that cannot be solved by changing PATH. Please do not try > to > divert from this general problem. > > I'm with you there. I don't remember the ARC case # (I think it was the creation of /usr/gnu), but I actually argued the same thing on the conference call. I think the only difference is that When I hung up from the conf. call, I understood that while my argument was heard and understood, it wasn't deemed to be enough to change things, and I knew they decided to go ahead anyway. Ao I wasn't surprised when the gnu binaries appeared in /usr/bin.
I pushed for all gnu software to be installed in /usr/gnu, with an second (optional - but installed by default) package of soft links from /usr/gnu/to /usr/bin for the programs everyone wanted to put in /usr/bin. That way if I elected, I could use PATH for my users to allow them total flexibility, without changing the default for other installations who just expect everything to be there. I suppose a /usr/some/path/imagemagik/ could have been created where all the binaries are installed, and a imagmagik links pkg (again installed by default) could have been added also to make them appear in /usr/bin, but leave the admin installing the machine the option to remove them. I would think even that might have been good enough for you: a /usr/some/path/schilly/... instalation location for your stuff, with a second 'links' pkg (not installed by default, I would assume given Sun's view that Imagemagik.is more widely used.) but available for those who wanted to put your programs in /usr/bin. I imagine that Sun either didn't want to start a precendent for this, nor have to set criteria for what can and can't be have it's own /usr/some/path/SomeCollection directory. Still in my mind it's the only method that retains flexibility and scales(mostly.) This allows the admin to customize the machine defaults, without denying the users the ability to override the admins choices. And it still lets Sun keep it's 'serendipitous discovery' (is the right name?) policy alive. Seemed like it should have been win win, and covered all the requirements for everyone at the time, and I never felt that I heard a good reason not to do it. The focus of my argument was that I maintain a network of machines, where I need to build and install GNU and other tools myself, for various reasons the ones included in Solaris will never be good enough. I keep these apps on an NFS share, and therefore I don't want to put them in front of /usr/bin in PATH, but with these GNU (and other tools) integrated into /usr/bin, I'm forced to either prepend them to the PATH, or not install the corresponding Solaris packages. So far I've elected to not install the packages whenever possible, and that has worked for me so far. However I see the day coming when (because it's in Solaris now,) someone codes some other part of Solaris to depend on these programs, and not installing these packages won't be an option. I suppose I'll revisit the argument then. -Kyle > Jörg > > _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
