[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Propsoal: New install tool
From: |
Kim Lester |
Subject: |
Propsoal: New install tool |
Date: |
Sat, 12 Apr 2003 03:10:23 +1000 |
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 ;-)
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.
* 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.
* 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.
* one isn't absolutely guaranteed that every make install will obey
--prefix and not "paint outside the box" - although I presume most
play nice.
* 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.
* 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.
* 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.
* 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.
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.
--------- Sample Install.conf file ----------
%config
# these are variables
name = PACKAGE_NAME; # eg fakeroot
version = PACKAGE_VERSION; # eg: 0.5
%header
# these are not really variables, everything after ":" is bascially free text
Author: AUTHOR
Packager: PACKAGER
Summary: SUMMARY
Dependencies:
%filelist
# default uid, gid, can be numeric or symbolic
uid=0;
gid=0;
destRelPrefix=/usr/local/sys/$name; # $name -> fakeroot in this case
# all relative paths below have destRelPrefix as their root.
# all absolute paths remain unchanged
DIR { # dirs havea default mode of 755
.
bin
lib
man
man/man1
man/sv
man/sv/man1
}
FILE (mode=755; gid=other) { # can specify group defaults here
# install location source file location
# ---------------- --------------------
bin/faked src/bin/faked
bin/fakeroot src/bin/fakeroot
# explicitly specify uid, gid and mode for this file
etc/faked src/scripts/faked (uid=123; gid=other; mode=600)
}
# redefines gid for subsequent groups
gid=other;
FILE (mode=644)
{
lib/libfakeroot.a src/lib/libfakeroot.a
lib/libfakeroot.la src/lib/libfakeroot.la
lib/libfakeroot.so.0.0.1 src/lib/libfakeroot.so.0.0.1
man/man1/faked.1 doc/man/man1/faked.1
man/man1/fakeroot.1 doc/man/man1/fakeroot.1
man/sv/man1/faked.1 doc/man/sv/man1/faked.1
man/sv/man1/fakeroot.1 doc.man/sv/man1/fakeroot.1
}
# symlinks
SYM {
lib/libfakeroot.so ./libfakeroot.so.0.0.1
lib/libfakeroot.so.0 ./libfakeroot.so.0.0.1
/usr/local/etc/init.d/faked ../../sys/fakeroot/etc/faked
/usr/local/etc/rc3.d/S99faked ../../init.d/faked
}
----------------------------------------------------------------------
Kim Lester,
Senior Engineer,
Datafusion and Visualisation Systems
www.dfusion.com.au
- Propsoal: New install tool,
Kim Lester <=