[csw-maintainers] User requests symlinking from /usr/bin to /opt/csw/bin

[Brian Hill]

Nicolai Schwindt wrote:
> [...]
>  
>>>> There's a user request to create symlinks from /usr/bin to
>>>> /opt/csw/bin, for instance, /usr/bin/lpr --> /opt/csw/bin/lpr.
>>>>         
>>> I think it's not good.
>>>
>>> It will fail in a zone with global /usr.
>>>       
>> It is a purely optional package that depends on cups and its whole  purpose
>> is to replace the SysV-lp system. Nothing more. If you don't want the
>> system replaced you don't install this package. We may choose a slightly
>> modifed prefix like
>>    CSWScups (CSW Solaris cups)
>> or something to mark that it doesn't install in /opt/csw but replaced
>> Solaris core functionality.
>>     
>
> Which I can do by adjusting the order of my PATH elements.
> Nothing belongs in /usr besides what SUN puts there.
> The zones are are an example where this fails, and also the fact that I've seen several customer
> mount /usr read only.
>
> Besides that, it is law - at least to me - that's why there is /opt.
> This is not linux !
> Also I do not see cupsclient as purely optional. CSWcupslibs gets pulled in on behave of several
> packages. To be able to verify you setup one will need CSWcupsclient. The actual printing can
> be done with the onboard toolchain.
>
> Apart from that - what happens to /usr/bin/lpr, is it deleted ? Is SUNWpcu deinstalled ?
>
> Before making such modification one should think about making his on distribution rather than
> build packages for an existing one.
>
>
> Nicolai

Hi Nicolai,

Solaris does not exist in its a vacuum. :-) As a system manager, I want
to deploy as few OS-specific solutions as possible; that is, I don't want
to defer to FHS (File Hierarchy Standard) on Linux systems, which most
3rd-party Linux rpms follow to install files, but then have to modify
/etc/default/login and other files on Sun systems, and /opt/local or
/sw on Macs in some other file, if that's even possible on Macs (still
looking into how Darwin handles a global PATH). Remote execution (ssh,
rsh) and cron are additional examples of how trying to add to a PATH
globally becomes difficult. And that Solaris 10 has the issue of zones
affecting /usr isn't persuasive enough.

To address this, I have made /usr/local on my systems strictly a symbolic
link tree, with symbolic links pointing all over the place, which has
helped a lot, but it's really not a substitute /usr/bin.

The sysadmin is the user in the 'user experience' that CSW works for. We
could argue forever about the direction that the PATH vs. /usr/bin
debate is headed in the broader UNIX world, but CSW could offer at
least one other avenue, especially if someone is CSW land is willing to
offer that flexibility to deal with this. No solution will tip-toe with
complete success around an installed OS. CSW already does it in /etc/rc*
and /etc/init.d (I have to move CSW's init files out of the way after
installing CSW's tools because I use my own init file method).

Creating /usr/bin symbolic links in optional pkgs is as reasonable as
modifying /etc/default/login, /detc/default/su and/or /etc/profile &
/etc/csh.login.

That a filesystem 'namespace' clash can happen somewhere in user land
is a guarantee, but not all sysadmin's should be held hostage in the
effort to avoid that clash.

My 2 cents.

Brian