Changes to the BUILD and INSTALL scripts (Men-At-Work)

[Dennis Veatch]

On Thursday, January 26, 2012 8:52:13 PM Dave Brown wrote:
> On Wed, Jan 25, 2012 at 02:11:18PM -0800, Auke Kok wrote:
> > On Wed, Jan 25, 2012 at 07:27:45AM -0500, Dennis Veatch wrote:
> > > Well alright then. Did I miss some background conversations :)
> > 
> > perhaps, but likely not - I haven't been around brainstorming in #lunar
> > exactly much
> > 
> > > I think I can see where you are going with this to a point but
> > > missing what is to be gained; aside from some obvious things. Like
> > > simplifying the BUILD scripts to only perform configure and make.
> > > 
> > > Beyond that I will assume this is a subset of some other changes you
> > > have in mind.
> > 
> > Simplification is not actually the goal, and I don't think that this
> > step
> > actually simplifies things much, as right now one could have an empty
> > BUILD file sitting around, something we didn't have before.
> 
> Why not just do exactly what we do with other optional files--just
> delete it?  If something has a GNU-autoconf default build, just delete
> the BUILD file altogether and let the default handle it.
> 
> > There are several big problems with Lunar's way of building things, and
> > not much you can do about it unless we split the BUILD up into two
> > parts.
> > 
> > But, on the short term, there are zero features that you get from this,
> > which is why it never happened until now.
> > 
> > It does enable quite a few features, that are extremely interesting, and
> > in my perspective are vital to make Lunar work going forward. Right now,
> > moonbase is practically tipping over, and this will result in build
> > breakage all over more and more.
> 
> Yeah yeah.  To make an omelette, sometimes you have to break some eggs.
> 
> > So, back to what this will give us:
> > 
> > 
> > sandboxed installation: We can now use fakeroot-ng or similar to not
> > actually install files into the live system, but into a sandbox. This
> > will allow us to actually prevent system files from being overwritten,
> > complain if this happens, and it will also make upgrades much more
> > safe!
> 
> I have a use case for this!  emacs and ctags have a stupid conflict--the
> "ctags" binary.  There's no mechanism within the emacs build, short of
> patching the Makefile, to install ctags as anything other than ctags.

You mean this line from the emacs BUILD does not resolve that issue?

  OPTS+="--program-transform-name='s/ctags*/etags/'"

> 
> Stick it in a sandbox, though, and you can have a PRE_INSTALL script
> that digs into the sandbox, renames "ctags" to "etags", and removes the
> whole conflict.
> 
> I am seriously warming to this whole idea.
> 
> --Dave

-- 
Dennis Veatch
Lunar-Linux Developer
http://lunar-linux.org