info-cvs
[Top][All Lists]
Advanced

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

Re: Stow


From: Paul Sander
Subject: Re: Stow
Date: Fri, 25 Oct 2002 13:49:26 -0700

>--- Forwarded mail from address@hidden

>On Fri, Oct 25, 2002 at 09:58:15AM -0700, Paul Sander wrote:
>> Each platform usually has a packaging method available as well.  Solaris,
>> IRIX, HP-UX, AIX, Linux, and *BSD Unix all have packaging systems supplied
>> with them.  Microsoft's systems have commercial products, e.g. InstallShield
>> and InstallAnywhere that perform these tasks.

>Don't they all take a fair amount of work to package up a given
>distribution?

I've successfully automated packaging for Solaris, HP-UX, IRIX, and AIX
by writing thin wrappers around the native tools and using a single
spec to drive them all.  I've also seen examples of automated RPM specs.

InstallShield is hard to automate, particularly if you have rolling baselines.
InstallAnywhere couldn't be automated prior to v4.0, but I understand that
it's gotten better in the past few months.  On the Unix side, AIX is the
worst because they supply tools only to install packages, not to build them.

>> Typically, the administrators of these systems know how to use the native
>> packaging tools, so using yet another "non-standard" one (in their eyes,
>> even if it's portable) is a trade-off.

>If you're building a binary package for wide distribution,
>absolutely -- whether that distribution is to the public or to
>many similar machines within a large organization.

>But if all you're trying to do is manage your own /usr/local,
>when its contents are primarily third-party stuff you've built
>from source, writing an RPM spec file or the like for every
>darned source tarball you download seems to me to be more work
>than it's worth.

Shouldn't be too hard to write a script that converts the output of
"tar -tf" into an RPM spec.

>In my case, there are eight or ten machines, with at least three
>flavours of *NIX.  That'd be three package-spec files to write
>per package.  The overhead would dwarf any advantage.

Again, there's the trade-off.  If you want to cater to established
admins of the target machine, use the native packages.  If you want
uniformity, use stow.  Either will work, it's just a question of who
you can inconvenience more.

>--- End of forwarded message from address@hidden





reply via email to

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