[M3devel] Reasoning for /usr/local/cm3 ?

Martin Bishop mbishop at esoteriq.org
Wed Sep 23 18:32:21 CEST 2009


Jay K wrote:
> > > 'source /etc/profile' with every shell. And if I symlink it, it causes
> > > problems.
> >
>  
> Symlink should work.
> Symlink /usr/bin/cm3 to /usr/local/cm3/bin?
> Hardlinks would not likely work.
>  
>  
> /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.
> "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...
>  
>  
> Some people would use the shorter /opt/cm3.
>  
> Personally I use /cm3, possibly symlinked to ~jay/cm3.
>   (Note: symlinks not necessarily available!)
>  
> 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.
>  
> Some folks use
>   /opt/pkg1
>   /opt/pkg2
>  
> and then blow up $PATH with lots of entries. Others use symlinks into 
> the shared /usr/bin and whatnot.
> Maybe others just use full paths.
>  
> There is no perfect answer here. Every approach has (large, glarying) 
> advantages and disadvantages.
> 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.
>  
> 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.
>  
> Some people use a userid per package.
>  
> One more thing before I shut up ... we produce package manager 
> indepent packages.
> So not much of an installer/uninstaller, no package database.
>  
Thanks, I guess there really isn't a simple answer...

> I do have code to produce .deb files checked in. I should enable that 
> soon.
> 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...)
>  
You should definitely provide debs for the stable release.  Will help 
get more people to try it out.
>  
>  - Jay
>
>
>  
> > Date: Wed, 23 Sep 2009 11:18:41 +0200
> > From: wagner at elegosoft.com
> > To: m3devel at elegosoft.com
> > Subject: Re: [M3devel] Reasoning for /usr/local/cm3 ?
> >
> > Quoting Martin Bishop <mbishop at esoteriq.org>:
> >
> > > Why does everything install into /usr/local/cm3/* ? I tried editing my
> > > PATH variable to get the cm3 binary in there, but I still have to
> > > 'source /etc/profile' with every shell. And if I symlink it, it causes
> > > problems.
> >
> > The paths are different on different systems. /usr/local/cm3 is just
> > the system-specifics-ignoring default of a generic cm3 installation.
> > System-specific packages are currently being prepared by some
> > people, but not yet finished as far as I know. There should be
> > mails in the archives about download locations.
> >
> > > Is there a reason to not just install to normal positions like 
> /usr/bin
> > > and /usr/lib, etc? Is it possible to tell cminstall where to install
> > > other the default /usr/local/cm3 ?
> >
> > Sure. Just give cminstall the target directory as argument.
> > It will always install a complete tree though (bin, lib, pkg, doc, 
> www, ...)




More information about the M3devel mailing list