Mailing List Archive

Alan Burlison wrote :
|| I have to supply Perl on a total of eight machines, all binary
|| compatible. I don't want to have to build it on each machine, and would
|| prefer to build it into a svr4 installable package. I have done this
|| manually for perl5.001m, but it would be nice to automate the process,
|| and to provide a Perl module to form the basis of an OS-independant
|| install package.
||
|| The main problem is getting a definitive list of the files that are
|| required. The MAMIFEST has lots of stuff that is not needed after build
|| time, so that's not much use.
||
|| Another option is the installperl and installman programs, with the -n
|| option to produce a list of actions without actually performing them.
|| The trouble is that if you have already installed perl, most of the
|| actions don't get performed if the files haven't changed :-(
||
|| The last option is to hack apart installperl and installman & mimic their
|| operation. I suspect that this is the only realistic option.
||
|| I suppose I *could* combine installperl and installman, adding
|| functionality to support building OS-installable packages. An uninstall
|| option would be nice (although I'm sure nobody would ever want to
|| uninstall Perl ;-)
||
|| I have a vested interest in doing this - what does the panel think?

I'd love to see it done. I have on my wish list a much bigger
project that includes this as a subset. (Unfortunately, I won't
be able to even start serious design on this for months.) My
need/wish is for a collection of facilities to control building
and installing portions of a suite of programs. For a (set of)
items, I want to be able to put together a "source" release,
which can be "compiled" and used to produce a "binary" release,
which can be "installed". A component release (source or
binary) would contain a manifest, a pre-requisite list (which
specifies component releases which must be present before this
component can be processed), a set of questions that must be
answered before this component release can be processed, and
directions for processing (install procedure, makefile, etc.).

The inter-relationships between components can be quite tricky -
for example, the way I build perl4, the sdbm component must be
installed as a pre-requisite to building perl, since libsdbm.a
and sdbm.h must be available for Configure to find and use (but
the sdbm component is *not* a pre-requisite for installing perl
and need not be present at all on the final installation site).
The questions and answers are also tricky - it is useful to
distinguish between questions that are needed for compiling
(i.e. these are usually related to the platform being compiled
upon) and for installing (while these are related to the
specific site). I'd like to be able to share questions and
their answers between components - for example, the answer to
"What mail address should receive messages about internal
problems?" and "What address format, domain or site name, and
local address should be used for Reply-To?" (that's not one
question of course) would be used by more than one component.
It would be nice to be able to patch in site-specific answers at
install-time, even of the answers have compiled into binary
programs, but that can be really messy. Upgrading/re-installing
is another cans of worms - you'd like to be able to re-use
answers to questions when you're upgrading, you don't have to
have as complete a source package just what has to be changed,
and so on. (As I said above, a serious design is needed for
this project.)

--
Maybe we can fix reality one of these days. | John Macdonald
<- Larry Wall Carl Dichter -> | jmm@Elegant.COM
I'd be happy if we could just index it. |

Alan> I suppose I *could* combine installperl and installman, adding
Alan> functionality to support building OS-installable packages. An uninstall
Alan> option would be nice (although I'm sure nobody would ever want to
Alan> uninstall Perl ;-)

Alan> I have a vested interest in doing this - what does the panel think?

I too would like to be able to easily make a svr4 package from perl. My
reason is that I want to be able to make perl part of our normal OS release
and the easier it is to get it in PKG format, the more likely we are to
keep current with the latest release. Perhaps it would be possible to come
up with some kind of "database" similar to the "prototype" file that the
PKG tools need and have the perl install scripts run off this database
and provide other scripts which can build a prototype file from the same
database.

--
Tom.Horsley@mail.hcsc.com
Home: 511 Kingbird Circle Delray Beach FL 33444
Work: Harris Computers, 2101 W. Cypress Creek Rd. Ft. Lauderdale FL 33309
Support Project Vote Smart! They need your support in non-election years too!
(email pvs@neu.edu, 1-800-622-SMART, http://www.vote-smart.org)

On Wed, 22 Nov 1995, Alan Burlison wrote:

> I have to supply Perl on a total of eight machines, all binary
> compatible. I don't want to have to build it on each machine, and would
> prefer to build it into a svr4 installable package. I have done this
> manually for perl5.001m, but it would be nice to automate the process,
> and to provide a Perl module to form the basis of an OS-independant
> install package.
>
> I have a vested interest in doing this - what does the panel think?


You should check out the sections of the INSTALL document on
'Changing the Installation direcoty' and
'Creating an installable tar archive'

which address just these issues.

I wouldn't mind having the ability to wrap it up in an svr4 package,
I just don't have the background, experience, or need to do it myself.

Andy Dougherty doughera@lafcol.lafayette.edu