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

[Dave Brown]

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.

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