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 _______________________________________________ maintainers mailing list [email protected] https://lists.opencsw.org/mailman/listinfo/maintainers
