autoconf
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Propsoal: New install tool


From: Bernd Jendrissek
Subject: Re: Propsoal: New install tool
Date: Mon, 14 Apr 2003 15:48:32 +0200

On Sat, Apr 12, 2003 at 03:10:23AM +1000, Kim Lester wrote:
> I have a proposal for a new "install" tool which I believe would solve
> many people's problems. I have written such a tool and it solved
> my problems ;-)

You forgot to say where I can find this magic tool! :)

> I hope this is the right group to open discussion in...
> 
> I'm not an auto* expert, nor am I up to date with recent developments
> in the gnu arena, so please bear with me. If I have made any major
> factual errors I would appreciate correction, I have no particular
> angle/bias, I just want to make tools that make life easier.
> 
> Bottom line is I have developed a tool which does something very
> useful for me and which I may be able to share with the community.
> 
> 
> Background/Context:
>     * Many apps, especially gnu tools, use "make install" target
>       that does various installs and copies.

Which is great, except that some need:
  make prefix=/tmp/destdir/usr install
  make DESTDIR=/tmp/destdir install [so far my favourite]
  make prefix=foo tooldir=bar libdir=baz install [binutils is like this]
  su -c 'make install' [Ugh.  I couldn't seem to install python without this]
    or equivalent chroot foo 'make install'

The 90% of packages which behave well with DESTDIR aren't the problem.  I
hope your program can address the *other* 10% of packages.

>     * Many apps start out life as an automake enabled tarball but
>       end up in some form of packaging system
>     * Many app installers want to configure and build ONCE on a system
>       and install identical copies on a range of local systems.
> 
> Observations:
>     * It is difficult to work out what "make install" is actually
>       going to do.

Other than by doing it... I know the frustration.

>     * Many(?) applications are not trivially relocatable because
>       they compile the value of say --prefix into their code
>       (so you can't use --prefix=/some/temp/root and then do a make install)
>     * make DESTDIR=tempPrefix install   isn't universally implemented.

Ugh, yes.  Now it would be fine if packages would *reliably* fail to install
if some part of them didn't listen to DESTDIR, but I've seen one or two
that simply *ignore* the error.

>     * one isn't absolutely guaranteed that every make install will obey
>       --prefix and not "paint outside the box" - although I presume most
>       play nice.

I didn't have much luck installing python into a DESTDIR...

>     * For me to find out where soemthing is going to install I have to rely
>       on make DESTDIR=blah install.
>       If I want to know the true ownership and perms etc I have to do it
>       as root.

coreutils flip-flops depending on whether it's root or not: it thinks it
*has* to install su suid root.

>     * it is not always desirable to do things as root (as we all know)
>       so I use fakeroot wrapped around make install. (Chroot is just too
>       much of a headache). The resultant temporary install dir can then
>       be tarred up (for example) with correct permissions etc and untarred
>       on other similar systems in a managed environment.
> 
> Proposal
>     * Develop a tool which contains a straight forward configuration file
>       containing where to get files from the source tree and where to place
>       them in the install tree.

I'm not sure I understand fully: does the config file get *generated*, or
does the package maintainer *write* it?

>     * Add a useful area to store version, author and maintainer etc info
>       (having them "buried" in lines like AM_INIT_AUTOMAKE(hello,0.1)
>       is a little obscure, although many programs use something "simpler"
>       like version(.h) etc.
>     * A program reads the config file, uses it to get the files from the 
> source
>       tree etc and copies them to the specified destination tree.
>       In this way it would completely replace the standard "install" tool.
>     * Package maintainers (eg debian) would use the same config file (parsed 
> by
>       a common library routine) and add their own backend which takes extra 
> debian
>       data from other locations and builds a debian package.

Oooh, I love it already!

>     * The tool would handle multiple install variants (eg developer vs 
> runtime)
> 
>       Note: I'm NOT suggesting auto* etc be a packaging tool. What I am 
> suggesting
>       is that a install information file would make package makers and all
>       installer's     lives much easier.
> 
> Bottom line
>     * I needed such a tool, and I have developed it.
>       It works nicely for my purposes and is 95% general enough for others to
>       benefit from.
>       This tool, whilst designed to replace install in future autoconf etc 
> archives,
>       can also be used (via related utilities) to create the install config 
> file
>       from existing "make install" based apps to simplify migration.

Er, you mean your new install would be compatible with the install that
makefiles expect?  Except that it wouldn't actually *do* the install, but
just *note* it on a cribsheet?  If you want to maintain compatibility with
standard install, you'd actually have to *install* the files and dirs at
some point...  What would you propose to be a good place to do this?

>       I enclose a sample config file (termed Pkginfo.conf) although
>       I use it for packaging it might be renamed "Install.conf" 
>       for example, to avoid anyone getting worked up about auto*
>       not being a pkg tool.
>       In this sample the UPPERCASE values would be replaced with something 
> sensible.
>       The tool supports simple variants (dev vs runtime say) these are not 
> shown.
>       The tool supports variables (eg version could be passed into the 
> install tool
>       from an outside location rather than encoded in file.
> 
>       The sample is loosely based on the fakeroot tool but I've added misc
>       invented bits to give a feel for what it can do.
> 
> Feedback, suggestions welcome.

Suggestion: gimme the URL.


To those package maintainers who haven't yet autoconfiscated their packages,
or maintain Makefile.am's with lots of rules, please, PLEASE, BIG PRETTY
PLEASE, even if you don't completely automake-ify the package, just PLEASE
support DESTDIR.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]