[Top][All Lists]

[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 15:38:02 -0700

>--- Forwarded mail from address@hidden

>On Fri, Oct 25, 2002 at 01:49:26PM -0700, Paul Sander wrote:
>> Shouldn't be too hard to write a script that converts the output of
>> "tar -tf" into an RPM spec.

>Still doesn't help me to keep multiple versions installed and
>usable at once.  Or can RPM etc. manage that trick somehow?

The packaging systems themselves track the installed versions.  The
idea behind the script to convert a tar file into an RPM package is
to take not only the tar file as input, but also the name of the package,
version number, target location, etc.  Then once the tar file is converted
into an installable package, you gain the benefits of the package for
administration purposes.

>> >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.

>I *am* the admin of the target machines, and I swear by
>uniformity.  Poof, conflict resolved :-)

Fair enough.

>Again, that last statement is *only* true for my sort of
>situation; I was never attempting to claim that Stow was useful
>for distributing binaries to people other than the person running
>"make".  But then, my sort of situation is pretty common among
>consumers of open-source software -- people with home Linux or
>BSD boxes, admins of small-business sites, etc.

Well, in the situation that you describe, there's really only type of
machine involved.  In that event, it really doesn't matter if you use
the supplied tools or Stow.  Either way, there's only one packaging
system in use.

The place where Stow becomes valuable is when there is a mixture of
architectures and the admins don't want to bother themselves with
learning a different tool to do the same thing on every architecture.
But even then, the OS and other add-ons come in native packages so they
have to learn them anyway.

If you're producing products for sale to run on multiple architectures,
there's another argument for uniform packaging products.  But if you go
against the customer's best practices then you're only going to make an
unfavorable impression.  In that situation, laziness among the salespeople
(who must frequently install demos) and QA (who must frequently install
test systems) seems to be the most compelling argument favoring tools
such as Stow.

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

reply via email to

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