Re: More an autopackage

[Derek R. Price]

Geoffrey Wossum wrote:

> > You can use GNU m4 or PERL in autoconf and automake, as these are
> > maintainer-only tools. If autopackage is a package-installer tool (i.e. a
> > native package front-end) the choice of implementation language is almost
> > restricted to "/bin/sh" or "/bin/sh" and probably "/bin/sh" :-)
>
> I would imagine that 95% of the people using autopkg would be package
> maintainers.  These people probably would install any language required if
> it made their job as package maintainers easier.  There will be some
> people who want to compile their own stuff, but also want features a
> packaging system provides, like dependency tracking and uninstall.  These
> people would probably also be willing to install Python or Perl to get the
> features.

I think we were discussing the difference between a package tool that the
maintainer runs and the portion that gets run when an end user types, 'make
install-rpm', or whatever.  Then, I think the issue is whether the source data 
is
coming from the Makefile.am or the Makefile generated by a configure run.

I believe Tom Tromey's point was that using the Makefile.am means a lot of
overhead figuring out which targets are conditional and the like - things which
Automake already figures out and already incorporates into a Makefile.in and in
conjunction with Autoconf & configure into a final Makefile.  Note Tom's 
previous
posts on some of the aspects of Autopackage support which might be useful to
integrate into the Makefile.am and Automake.

The second point is that any tool that gets used when a user types, 'make
install-rpm', is going to have to be written in Bourne shell.  This would seem 
to
include the package tool since it is dependent on targets defined in the
Makefile.am but which may or may not be present in the final Makefile.

I'm still thinking a two stage process is in order:  A script that scrapes the
Makefile and a meta spec file (since the make process is invoking it this could
simply mean it is passed the appropriate data) to create the package manager
specific spec file and a package manager front end tool that accepts a uniform
set of package manager commands and options and turns them into commands and
options for the appropriate package manager and invokes it.  Whether this action
is to turn the spec file (and with RPM, the result of a 'make dist' - something
else which will require Automake support, I think) into a package or to install
an existing package is dependent on the target and thus the options passed into
the tool...

Derek

--
Derek Price                      CVS Solutions Architect ( http://CVSHome.org )
mailto:address@hidden     OpenAvenue ( http://OpenAvenue.com )
--
82. Hold a hard drive to your ear -- listen to the C.