On Sun, Jan 9, 2011 at 2:33 PM, Maciej (Matchek) Blizinski <[email protected]> wrote: > No dia 9 de Janeiro de 2011 15:25, Philip Brown <[email protected]> escreveu: >> >> certainly that is not appropriate. I suppose it would be helpful to >> explicitly call out in this discussion, >> "programs should not be configured with any prefix other than >> /opt/csw, unless there is a compelling requirement to have a >> subprefix". (such as an ongoing need to support more than one version >> of a particular program installed at a time) .../
> Fair enough. However, even an ongoing need to support more than one > version of a program does not necessarily mean that we need to compile > programs with a different prefix. I agree. Rather than quoting the next chunk of your email, I'll just say feel free to make the language about "compelling requirement" tighter. Certainly, there are some programs that can cleanly support multiple versions installed, without subprefixes. Then again, there are others which do not. > The general case of the statement probably doesn't need much > explanations. You don't have separate web servers for Firefox, Google > Chrome and elinks. Just because one client is special, doesn't mean > you need to make the shared resource special. Interesting that you bring up firefox. Because is another thing that effectively "has its own prefix", with symlinks from /opt/csw/bin so users don thave to tweak their path. [well okay its a wrapper script not a symlink :) but same principle. All the real libraries live under the firefox prefix] >>> ... Any other /opt/csw >>> based custom prefixes will never be self-sufficient. >> >> its not about being self-sufficient. it was most likely about typical >> sysadmin methodologies in deciding what to clean up. >> "Hmm.. this filesystem is way too full. what can I get rid of cleanly? >> lets run du -k" >> Then when you get obvious "big directories" that you are not using, >> you can remove them by "appropriate" means, which may still be >> "pkgrm". There's probably other reasons lurking... i think I dont >> remember the full reasons. > > I feel this branch of our discussion borders on ridiculous, but okay, > let's continue if you wish to. >... > If you want to cleanly get rid of some files, removing /opt/csw/mysql5 > might be a very bad move if libmysqlclient is in /opt/csw/mysql5/lib. > You might have a program you use (say, php5 or bacula, or postfix) > linking against libmysqlclient. [...] I explicitly said in my message (which you even quoted), that in such an instance, I may use pkgrm to remove the files. For initial diagnosis/investigation, sometimes it's nice to be able to use "normal' filesystem tools rather than pkg ones, even if actual file add/removal is handle by pkg tools. So in that case, user would get a warning on pkgrm that something else is using it. > Removing /opt/csw/mysql5 may > effectively disable your website, or mail server, or whatever it is > you're running. In such scenario, if you insist on it, having > libmysqlclient located under /opt/csw/lib is a better option, because > your web or mail server will continue functioning even after the > removal. contrariwise, if someone discovers that they are using the shared libs from mysql, they will probably find it useful to have the client around for debug/admin purposes. It then becomes a slippery slope down, "well, we have the 'real' shared lib in /opt/csw/lib, so lets have the 'real' client prog in /opt/csw/bin".... On the other hand, if symlinks are good enough for the client prog that is sub-prefixed, it should be good enough for the shared lib that is sub-prefixed? There's the other side of the consistency sword. _______________________________________________ maintainers mailing list [email protected] https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
