<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
> > 'source /etc/profile' with every shell. And if I symlink it, it causes<BR>> > problems.<BR>> <BR>
<BR>
Symlink should work.<BR>
Symlink /usr/bin/cm3 to /usr/local/cm3/bin?<BR>
Hardlinks would not likely work.<BR>
<BR>
<BR>
/usr/local/cm3/bin is used instead of /usr/bin, because it makes it clear what goes/came together and uninstall is just a recursive delete.<BR>
"uninstall is just a recursive delete" is something a lot of people like, and sometimes it is available, sometimes not. What about that PATH=/usr/local/cm3/bin:$PATH tidbits left behind in ~/.bashrc that user put in manually...<BR>
<BR>
<BR>
Some people would use the shorter /opt/cm3.<BR>
<BR>
Personally I use /cm3, possibly symlinked to ~jay/cm3.<BR>
(Note: symlinks not necessarily available!)<BR>
<BR>
I like that /opt is shorter, but there is much inertia/momentum behind /usr/local -- the default for autoconf, but granted, not /usr/local/pkg.<BR>
<BR>
Some folks use<BR>
/opt/pkg1<BR>
/opt/pkg2<BR>
<BR>
and then blow up $PATH with lots of entries. Others use symlinks into the shared /usr/bin and whatnot.<BR>
Maybe others just use full paths.<BR>
<BR>
There is no perfect answer here. Every approach has (large, glarying) advantages and disadvantages.<BR>
It is quite unfortunate but I really just try to ignore it. I believe you could spend, uh, infinite time discussing and implementing package management and as I said, you'd still have large glarying disadvantages.<BR>
<BR>
Of course there are various package managers that let you put everything "intermixed" in /usr and they keep track of what came from what and allow uninstall that isn't just a recursive delete.<BR>
<BR>
Some people use a userid per package.<BR>
<BR>
One more thing before I shut up ... we produce package manager indepent packages.<BR>
So not much of an installer/uninstaller, no package database.<BR>
<BR>
I do have code to produce .deb files checked in. I should enable that soon.<BR>
I'm inclined to just produce one large cm3-linux-x86.deb, cm3-linux-amd64.deb, cm3-linux-sparc.deb, etc. Not all the broken out packages that Olaf did. No dependencies. Not ubuntuv1, debianv4, etc., just claim that are fairly portable and see what happens. They could even be easily installed on non-Debian systems -- a .deb file is a very simple format esp. if you ignore the metadata file. It is as I recall an ar file with a metadata file and a nested .tar.gz or .tar.bz2 or .tar.lzma -- and due to the .tar.lzma option, much smaller than others. (And heck, we could make .debs for Darwin and Solaris; it really just takes like two lines of .sh to install them...)<BR>
<BR>
<BR>
- Jay<BR><BR><BR> <BR>> Date: Wed, 23 Sep 2009 11:18:41 +0200<BR>> From: wagner@elegosoft.com<BR>> To: m3devel@elegosoft.com<BR>> Subject: Re: [M3devel] Reasoning for /usr/local/cm3 ?<BR>> <BR>> Quoting Martin Bishop <mbishop@esoteriq.org>:<BR>> <BR>> > Why does everything install into /usr/local/cm3/* ? I tried editing my<BR>> > PATH variable to get the cm3 binary in there, but I still have to<BR>> > 'source /etc/profile' with every shell. And if I symlink it, it causes<BR>> > problems.<BR>> <BR>> The paths are different on different systems. /usr/local/cm3 is just<BR>> the system-specifics-ignoring default of a generic cm3 installation.<BR>> System-specific packages are currently being prepared by some<BR>> people, but not yet finished as far as I know. There should be<BR>> mails in the archives about download locations.<BR>> <BR>> > Is there a reason to not just install to normal positions like /usr/bin<BR>> > and /usr/lib, etc? Is it possible to tell cminstall where to install<BR>> > other the default /usr/local/cm3 ?<BR>> <BR>> Sure. Just give cminstall the target directory as argument.<BR>> It will always install a complete tree though (bin, lib, pkg, doc, www, ...)<BR> </body>
</html>