distrib a system for software distribution - an idea for software distribution

distrib a system for software distribution - an idea for software distribution

Post by Robin Slomkows » Wed, 07 Jan 1998 04:00:00



for a pretty copy see http://www.enteract.com/~rslomkow/distrib/distrib.html

This is a system I developed that I thought I would share with the the world
as it is a very helpfull way of keeping your system in order.  I personally
had lots of trouble tracking software version on my linux box.  The script at
the end is in perl because shell script was too slow and it was simple and
easy to just write.

The Distrib System

This article is to discuss a method of distributing software for a small to
moderate sized organizations to keep your software versions under control.

The core idea is that software should be in discrete identifiable bundles,
that can be identified by version, yet are still convenient to add to user
paths and easy to find current version of software.  It is furthermore
important that multiple version can co-exist on a system without
interfering with each other.

The traditional plan has been to install all locally compiled utilities in
/usr/local.  Installing everything in /usr/local/ makes it impossible to
distinguish versions and to remove all components of a particular application
as they have been spread everywhere.  Solaris has a pkg system that allows the
OS to keep a database of where all the files of a particular package are.
The Solaris pkg approach is difficult to write the pkg scripts, and does not
work well with having multiple version of something with the same name.

The Distrib idea is that you have a directory full of software packages named
the software packages name followed by the version number.   Then you make a
series of symbolic links of all the files and sub-directories to /usr/local/
as that is the traditional place users look for local applications.

Here is an example and explanation.

Take a software package called myapp version 12.3.4.  The first thing to do is
install the software into the package location.  In a sys-5 system should be
installed in /opt/myapp-12.3.4 ( or in a BSD derivative perhaps
/usr/local/pkg/myapp-12.3.4 ).  That directory you would have sub directories
as follows.

/opt/myapp-12.3.4/bin/
/opt/myapp-12.3.4/bin/myapp
/opt/myapp-12.3.4/bin/myapp-converter
/opt/myapp-12.3.4/lib/
/opt/myapp-12.3.4/lib/libmyapp.so
/opt/myapp-12.3.4/lib/myapp/libmyapp.cf
/opt/myapp-12.3.4/lib/myapp/libmyapp_defaults
/opt/myapp-12.3.4/man/
/opt/myapp-12.3.4/man/man1/
/opt/myapp-12.3.4/man/man1/myapp.1
/opt/myapp-12.3.4/man/man1m/
/opt/myapp-12.3.4/man/man1m/myappadmin.1m
/opt/myapp-12.3.4/sbin/
/opt/myapp-12.3.4/sbin/myappadmin

Now you have all of the parts of the application in one place with a name that
makes it easy to distinguish which version of the application is installed.
The next step is to create symbolic link to the /usr/local/ directory
structure so that users do not need to add /opt/myapp-12.3.4 to their paths to
have access to these tools.

The script distrib will create this parallel symbolic link directory structure
for you.

distrib /usr/local/ /opt/myapp-12.3.4/

Then you will now have real directories

/usr/local/bin/
/usr/local/lib/
/usr/local/man/
/usr/local/man/man1/
/usr/local/man/man1m/
/usr/local/sbin/

and these directories will  contain symbolic links to the original
applications and files.

/usr/local/bin/myapp -> /opt/myapp-12.3.4/bin/myapp
/usr/local/bin/myapp-converter -> /opt/myapp-12.3.4/bin/myapp-converter
/usr/local/lib/libmyapp.so -> /opt/myapp-12.3.4/lib/libmyapp.so
/usr/local/lib/myapp/libmyapp.cf -> /opt/myapp-12.3.4/lib/myapp/libmyapp.cf
/usr/local/lib/myapp/libmyapp_defaults -> /opt/myapp-12.3.4/lib/myapp/libmyapp_defaults
/usr/local/man/man1/myapp.1 -> /opt/myapp-12.3.4/man/man1/myapp.1
/usr/local/man/man1m/myappadmin.1m -> /opt/myapp-12.3.4/man/man1m/myappadmin.1m
/usr/local/sbin/myappadmin -> /opt/myapp-12.3.4/sbin/myappadmin

Now if you decide to install myapp version 12.3.5, you can now identify which
version of it you had, you can easily remove the previous version and all of
its parts because it is on directory structure in /opt/, furthermore
if you just run

distrib /usr/local/ /opt/myapp-12.3.5/

you will replace all the symbolic links with the new version, and the old
version installed in /opt/myapp-12.3.4 if any of your users need it for there
applications if the new version is not fully backwards compatible.  But in
/usr/local/ so most of your users are using the latest version without
having to change their environment.

/usr/local/bin/myapp -> /opt/myapp-12.3.4/bin/myapp
has been replaced by
/usr/local/bin/myapp -> /opt/myapp-12.3.5/bin/myapp

*note* the current distrib script will remove all symbolic links in /usr/local/
*note* but will not touch any real files when used in this way.  The distrib
*note* script also has a -r for remove that will clean up all of that packages
*note* symbolic links of the source directory and it will remove empty dirs.

In conclusion the distrib method has given us a way to keep track of the
components of an application, given us a way make those components easily
accessible to users, and allows us to keep multiple versions of software.

Practical Considerations:

This takes additional time when installing software packages as you now need
to force them into the package directory.  I use this system quite extensively
with third party applications and development tools, Cobol compilers for
Unix, third party object libraries such as roguewave, etc..  I untar the
software into a directory named the product hyphen the version name.
Programs with the GNU configure script you can give the
--prefix=/opt/application-version flag when you run configure.  Also you can
modify makefiles, in cases where it is an extreme pain to compile, I have
installed under a userid install then do a

find /usr/local/ -user install -depth -print \ | cpio -pvdum
/opt/application-version

so it can now be easily kept track of and distributed to other systems.

I am offering this system to the UNIX admin community to be used and improved
upon.  It is free, you may modify re-write use, sell your implementation.
Though I ask you do not sell the idea as your idea.  And please contact me
with improved versions or conceptual improvements to the system.

Robin * Slomkowski
rslom...@enteract.com

-- the distrib script -- CUT - HERE --

#!/usr/local/bin/perl
#
# Robin * Slomkowski
# Wed May 21 09:03:38 CDT 1997
# This is distrib Versiion 2.1
#
# USAGE: distrib [-(v|r)] destination_dir [source_dir]
#
# -v is verbose mode that has additional error messages from
# the system.  -r is reverse mode, and it will take away everything
# that is a link of the source_directory. The script defaults to
# using the user's current directory as the source from wich to link.
#
# This is a re-write of an earlier script by the same name.  It is
# deseigned to aide in revision control.  It will safely and effectivly
# generate a parrellel structure of real directories and symbolic links
# in a place of your choice.
# Example you have /opt/myapp-12.34.56 with lib, bin, man
# subdirectories.  with distrib you could create /usr/local/ bin lib
# man that will contain symbolic links to all the originals so your
# users don't have to have complicated paths.
#
# When going forward it will unlink any existing symbolic links in its
# destination, but if it is anything other than a symbolic link it will
# just leave it.
#
# When removeing it will only remove links that connect to the source
# from which you are removing, it also will only remove empty
# directories.

#
# defaults
#

$MODE = "FORWARD" ;
$VERBOSE = "FALSE" ;
$SOURCE_DIR = $ENV{PWD} ;
$USAGE_MSG = "USAGE:  distrib [-(r|v)] destination_dir [source_dir]\n" ;

#
# Define some subroutines
#

sub usage_error {
        print "$USAGE_MSG" ;
        exit 1 ;

}

sub safe_link {
        if ( -l $_[1] ) {
                if ( $VERBOSE eq "TRUE" ) {  
                        print "UNLINKING $_[1] and replacing \n" ;
                }
                unlink "$_[1]" ;
        }
        if ( ( -e $_[1] ) && ( $VERBOSE eq "TRUE" ) ) {
                print "FILE $_[1] exist can't place link there\n" ;
        }
        else {
                symlink $_[0] , $_[1] ;
        }

}

sub safe_unlink {
        if ( -l $_[1] ){
                if ( "$_[0]" eq readlink("$_[1]") ) {
                        unlink $_[1] ;
                }
        }
        else {
                if ( ( -e $_[1] ) && ( $VERBOSE eq "TRUE" ) ) {
                        print "UNLINK: $_[1] is not a symbolic link \n" ;
                }
        }

}

sub make_dir {
        unless ( -e "$_[0]" ) {
                mkdir "$_[0]" , 511 ;
        }
        else {
                if ( $VERBOSE eq "TRUE" ) {
                        print "MKDIR:  $_[0] exists, will use existing dir\n"
                }
        }

}

sub rem_dir {
        local ( @LINKDIR ) ;
        opendir LINKDIR , "$_[0]" ;
        if ( -e "$_[0]" ) {
                @LINK_DIR = readdir LINKDIR ;
                close LINKDIR ;
                splice @LINK_DIR , 0 , 2 ;
                if ( $#LINK_DIR < 0 ) {
                        if ( $VERBOSE eq "TRUE" ) {
                                print "$_[0] is empty, cleaning up\n" ;
                        }
                        rmdir "$_[0]" ;
                }
        }

}

sub get_files {
        local ( @DIR_LIST , @FILES , $BASE_NAME , $ENTRY , $OUTPUT ) ;
        $BASE_NAME = "$_[0]" ;
        if ( -d $BASE_NAME ) {
                opendir DIR , "$BASE_NAME" ;
                @DIR_LIST = readdir DIR ;
                splice @DIR_LIST , 0 , 2 ;
                foreach $ENTRY ( @DIR_LIST ) {
                        unless ( -d "$BASE_NAME/$ENTRY" ) {
                                push @FILES , "$ENTRY" ;
                        }
                }
                return @FILES ;
        }
        else {
                if ( $VERBOSE eq "TRUE" ) {
                        print "ERROR:  $BASE_NAME not a directory\n" ;
                }
        }

}

sub get_dirs {
        local ( @DIR_LIST , @DIRS , $BASE_NAME , $ENTRY , $OUTPUT ) ;
        $BASE_NAME = "$_[0]" ;
        if ( -d $BASE_NAME ) {
                opendir DIR , "$BASE_NAME" ;
                @DIR_LIST = readdir DIR ;
                splice @DIR_LIST , 0 , 2 ;
                foreach $ENTRY ( @DIR_LIST ) {
                        if ( -d "$BASE_NAME/$ENTRY" ) {
                                push @DIRS , "$ENTRY" ;
                        }
...

read more »

 
 
 

distrib a system for software distribution - an idea for software distribution

Post by David William » Thu, 08 Jan 1998 04:00:00




Quote:

>for a pretty copy see http://www.enteract.com/~rslomkow/distrib/distrib.html

>This is a system I developed that I thought I would share with the the world
>as it is a very helpfull way of keeping your system in order.  I personally
>had lots of trouble tracking software version on my linux box.  The script at
>the end is in perl because shell script was too slow and it was simple and
>easy to just write.

>The Distrib System

>This article is to discuss a method of distributing software for a small to
>moderate sized organizations to keep your software versions under control.

>The core idea is that software should be in discrete identifiable bundles,
>that can be identified by version, yet are still convenient to add to user
>paths and easy to find current version of software.  It is furthermore
>important that multiple version can co-exist on a system without
>interfering with each other.

>The traditional plan has been to install all locally compiled utilities in
>/usr/local.  Installing everything in /usr/local/ makes it impossible to
>distinguish versions and to remove all components of a particular application
>as they have been spread everywhere.  Solaris has a pkg system that allows the
>OS to keep a database of where all the files of a particular package are.
>The Solaris pkg approach is difficult to write the pkg scripts, and does not
>work well with having multiple version of something with the same name.

>The Distrib idea is that you have a directory full of software packages named
>the software packages name followed by the version number.   Then you make a
>series of symbolic links of all the files and sub-directories to /usr/local/
>as that is the traditional place users look for local applications.

>Here is an example and explanation.

>Take a software package called myapp version 12.3.4.  The first thing to do is
>install the software into the package location.  In a sys-5 system should be
>installed in /opt/myapp-12.3.4 ( or in a BSD derivative perhaps
>/usr/local/pkg/myapp-12.3.4 ).  That directory you would have sub directories
>as follows.

>/opt/myapp-12.3.4/bin/
>/opt/myapp-12.3.4/bin/myapp
>/opt/myapp-12.3.4/bin/myapp-converter
>/opt/myapp-12.3.4/lib/
>/opt/myapp-12.3.4/lib/libmyapp.so
>/opt/myapp-12.3.4/lib/myapp/libmyapp.cf
>/opt/myapp-12.3.4/lib/myapp/libmyapp_defaults
>/opt/myapp-12.3.4/man/
>/opt/myapp-12.3.4/man/man1/
>/opt/myapp-12.3.4/man/man1/myapp.1
>/opt/myapp-12.3.4/man/man1m/
>/opt/myapp-12.3.4/man/man1m/myappadmin.1m
>/opt/myapp-12.3.4/sbin/
>/opt/myapp-12.3.4/sbin/myappadmin

>Now you have all of the parts of the application in one place with a name that
>makes it easy to distinguish which version of the application is installed.
>The next step is to create symbolic link to the /usr/local/ directory
>structure so that users do not need to add /opt/myapp-12.3.4 to their paths to
>have access to these tools.

>The script distrib will create this parallel symbolic link directory structure
>for you.

>distrib /usr/local/ /opt/myapp-12.3.4/

>Then you will now have real directories

>/usr/local/bin/
>/usr/local/lib/
>/usr/local/man/
>/usr/local/man/man1/
>/usr/local/man/man1m/
>/usr/local/sbin/

  Why not just point users at

  /opt/myapp and do

  ln -s /opt/myapp-12.3.4 /opt/myapp

  ls -1d /opt/myapp then shows

  /opt/myapp  -> /opt/myapp-12.3.4

  and all the directories underneath point to the right place

  /opt/myapp/bin = /opt/myapp-12.3.4/bin
  /opt/myapp/lib = /opt/myapp-12.3.4/lib

  etc.

  Then just do

  rm /opt/myapp
  ln -s /opt/myapp-12.3.5 /opt/myapp

  to upgrade..

- Show quoted text -

Quote:>and these directories will  contain symbolic links to the original
>applications and files.

>/usr/local/bin/myapp -> /opt/myapp-12.3.4/bin/myapp
>/usr/local/bin/myapp-converter -> /opt/myapp-12.3.4/bin/myapp-converter
>/usr/local/lib/libmyapp.so -> /opt/myapp-12.3.4/lib/libmyapp.so
>/usr/local/lib/myapp/libmyapp.cf -> /opt/myapp-12.3.4/lib/myapp/libmyapp.cf
>/usr/local/lib/myapp/libmyapp_defaults -> /opt/myapp-12.3.4/lib/myapp/libmyapp_d
>efaults
>/usr/local/man/man1/myapp.1 -> /opt/myapp-12.3.4/man/man1/myapp.1
>/usr/local/man/man1m/myappadmin.1m -> /opt/myapp-12.3.4/man/man1m/myappadmin.1m
>/usr/local/sbin/myappadmin -> /opt/myapp-12.3.4/sbin/myappadmin

>Now if you decide to install myapp version 12.3.5, you can now identify which
>version of it you had, you can easily remove the previous version and all of
>its parts because it is on directory structure in /opt/, furthermore
>if you just run

>distrib /usr/local/ /opt/myapp-12.3.5/

--
David Williams

Maintainer of the Informix FAQ
 Primary site (Beta Version)  http://www.smooth1.demon.co.uk
 Official site                http://www.iiug.org/techinfo/faq/faq_top.html

I see you standin', Standin' on your own, It's such a lonely place for you, For
you to be If you need a shoulder, Or if you need a friend, I'll be here
standing, Until the bitter end...
So don't chastise me Or think I, I mean you harm...
All I ever wanted Was for you To know that I care

 
 
 

distrib a system for software distribution - an idea for software distribution

Post by Robin Slomkows » Thu, 08 Jan 1998 04:00:00




Quote:>  Why not just point users at

>  /opt/myapp and do

>  ln -s /opt/myapp-12.3.4 /opt/myapp

>  ls -1d /opt/myapp then shows

>  /opt/myapp  -> /opt/myapp-12.3.4

>  and all the directories underneath point to the right place

>  /opt/myapp/bin = /opt/myapp-12.3.4/bin
>  /opt/myapp/lib = /opt/myapp-12.3.4/lib

>  etc.

>  Then just do

>  rm /opt/myapp
>  ln -s /opt/myapp-12.3.5 /opt/myapp

>  to upgrade..

The reason why not is doing the method you describe every application is in
separate directory.  Distrib allows it that all the xemacs, myapp, emacs, gcc
files all be in /usr/local/bin and all the man pages are in /usr/local/man
for all of those applications.  So does not need a very large path.  When you
are considering 40+ packages that gets very substantial.  And many applications
like gzip or less are considered default by users.  So in /usr/local/bin
you have.  Lets you have the advantages of one locations where users can go
for utilities and man pages without having to look for the directory
containing the application.

/usr/local/bin/
/usr/local/bin/less -> /opt/less-3.21/bin/less
/usr/local/bin/ssh -> /opt/ssh-1.2.21/bin/ssh
/usr/local/bin/ssh-kegen -> /opt/ssh-1.2.21/bin/ssh-keygen
/usr/local/bin/xemacs -> /opt/xemacs-19.14/bin/xemacs
/usr/local/bin/ispell -> /opt/ispell-3.1/bin/ispell

Then the you have a similar collection in /usr/local/man

 
 
 

distrib a system for software distribution - an idea for software distribution

Post by Robert Campbel » Thu, 08 Jan 1998 04:00:00



> for a pretty copy see http://www.enteract.com/~rslomkow/distrib/distrib.html

> This is a system I developed that I thought I would share with the the world
> as it is a very helpfull way of keeping your system in order.  I personally
> had lots of trouble tracking software version on my linux box.  The script at
> the end is in perl because shell script was too slow and it was simple and
> easy to just write.

> The Distrib System

> This article is to discuss a method of distributing software for a small to
> moderate sized organizations to keep your software versions under control.

> The core idea is that software should be in discrete identifiable bundles,
> that can be identified by version, yet are still convenient to add to user
> paths and easy to find current version of software.  It is furthermore
> important that multiple version can co-exist on a system without
> interfering with each other.

> The traditional plan has been to install all locally compiled utilities in
> /usr/local.  Installing everything in /usr/local/ makes it impossible to
> distinguish versions and to remove all components of a particular application
> as they have been spread everywhere.  Solaris has a pkg system that allows the
> OS to keep a database of where all the files of a particular package are.
> The Solaris pkg approach is difficult to write the pkg scripts, and does not
> work well with having multiple version of something with the same name.

> The Distrib idea is that you have a directory full of software packages named
> the software packages name followed by the version number.   Then you make a
> series of symbolic links of all the files and sub-directories to /usr/local/
> as that is the traditional place users look for local applications.

> Here is an example and explanation.

> Take a software package called myapp version 12.3.4.  The first thing to do is
> install the software into the package location.  In a sys-5 system should be
> installed in /opt/myapp-12.3.4 ( or in a BSD derivative perhaps
> /usr/local/pkg/myapp-12.3.4 ).  That directory you would have sub directories
> as follows.

> /opt/myapp-12.3.4/bin/
> /opt/myapp-12.3.4/bin/myapp
> /opt/myapp-12.3.4/bin/myapp-converter
> /opt/myapp-12.3.4/lib/
> /opt/myapp-12.3.4/lib/libmyapp.so
> /opt/myapp-12.3.4/lib/myapp/libmyapp.cf
> /opt/myapp-12.3.4/lib/myapp/libmyapp_defaults
> /opt/myapp-12.3.4/man/
> /opt/myapp-12.3.4/man/man1/
> /opt/myapp-12.3.4/man/man1/myapp.1
> /opt/myapp-12.3.4/man/man1m/
> /opt/myapp-12.3.4/man/man1m/myappadmin.1m
> /opt/myapp-12.3.4/sbin/
> /opt/myapp-12.3.4/sbin/myappadmin

> Now you have all of the parts of the application in one place with a name that
> makes it easy to distinguish which version of the application is installed.
> The next step is to create symbolic link to the /usr/local/ directory
> structure so that users do not need to add /opt/myapp-12.3.4 to their paths to
> have access to these tools.

> The script distrib will create this parallel symbolic link directory structure
> for you.

> distrib /usr/local/ /opt/myapp-12.3.4/

> Then you will now have real directories

> /usr/local/bin/
> /usr/local/lib/
> /usr/local/man/
> /usr/local/man/man1/
> /usr/local/man/man1m/
> /usr/local/sbin/

> and these directories will  contain symbolic links to the original
> applications and files.

> /usr/local/bin/myapp -> /opt/myapp-12.3.4/bin/myapp
> /usr/local/bin/myapp-converter -> /opt/myapp-12.3.4/bin/myapp-converter
> /usr/local/lib/libmyapp.so -> /opt/myapp-12.3.4/lib/libmyapp.so
> /usr/local/lib/myapp/libmyapp.cf -> /opt/myapp-12.3.4/lib/myapp/libmyapp.cf
> /usr/local/lib/myapp/libmyapp_defaults -> /opt/myapp-12.3.4/lib/myapp/libmyapp_defaults
> /usr/local/man/man1/myapp.1 -> /opt/myapp-12.3.4/man/man1/myapp.1
> /usr/local/man/man1m/myappadmin.1m -> /opt/myapp-12.3.4/man/man1m/myappadmin.1m
> /usr/local/sbin/myappadmin -> /opt/myapp-12.3.4/sbin/myappadmin

Check out a package called stow in  ftp://gatekeeper.dec.com/pub/GNU  it does this for you.

--
Robert Campbell
Software Developer
Geonexus Interpretive Modelling Corp

WWW: http://www.geonexuscorp.com/

 
 
 

distrib a system for software distribution - an idea for software distribution

Post by cjy » Thu, 08 Jan 1998 04:00:00


[Remove the nospam from my address to reply.]

Once upon a time, for the same reasons, I'd shove elm's stuff into
/usr/local/elm/  and link the key binaries into /usr/local/bin/.  Had
a little script to do it, not really sophisticated.

I was motivated to this, when I inherited systems and had
NO clue as to which versions of what were running.  Running
"elm -v" and "gtar --version" and whatever else isn't really
practical - especially when a small utility might not support
that.  What package does "sq" belong to?  It has no -h or -v
command; strings tells me nothing.  This was typical of dozens
of binaries.

I wanted something small and simple that let me also EXTRACT
a package for when a new machine came in (keeping a .tar.gz
version as well as the expanded version is not always practical).

I was poking through the GNU stuff and found STOW.  A perl
script.  Not much to it; really simple.  Mostly it meets my needs.
It enforces little, it's got a couple small bumps - I run the
"-n" (no action - like make) option before trying something new;
just to see.  Check it out.

I have /usr/local/.Packages/ (an arbitrary name).   Under this,
I put /usr/local/.Packages/elm-2.4/{bin,man/man*} and the
elm tree.  Note that I have version number and everything; that's
me, not stow.
Then, I run "(cd /usr/local/.Packages ; stow -v elm-2.4)"

Basicly, stow goes into the 'package' directory and links everything
there into the "../.." directory with some intelligence.  So
all the files under elm-2.4/bin will be linked into /usr/local/bin.
Ibid with elm-2.4/man/*.

Stow makes all the links for all the files in the ".." area (by
default);
in this case /usr/local/.  So elm-2.4/bin/elm is linked from
/usr/local/bin/elm.
Moreover:
 - I can REMOVE a package's links (stow -d $PACKAGE)
 - It will links a directory when it's unique to the package; eg.
   /usr/local/man/man2 might be a link to
../.Packages/rdist-6.1.3/man/man2
   if rdist had the only man2 pages (and is, here).
   This directory link will only be "exploded" (made a directory
   and each file inside made a link if another package had files in
   "$PACKAGE/man/man2/"
 - You can tell it to link into anywhere; "../.." is just the default.
 - Mostly, I can just tar up a package, move it to a new machine,
   untar it and stow it.
 - So what is "amplot"?  (I never found "sq" again), well let's look:
              amplot -> ../.Packages/amanda-2.4.0b4/sbin/amplot
   I know the version because of my (chosen) naming scheme.

It's easy (really easy) to use, you don't have to commit to it
(it will manage just a couple packages if you want to play with
it.  Shove some files into /tmp/testme/PACKAGE/ and see it link
them into /tmp/testme.  No privs.  One scripts.  Really handy
and lightweight.

Drawbacks:
 - Some people HATE sym links.  I like them more than
   hoping a state database is in good shape (ala depot).
 - Symlinks are slow over NFS - they require a number (3)
   of lookups compared to a file or hard link (a file).
   Not really a problem for me here.
 - It's algorithm for removing a package seems to search the
   tree just above (/usr/local in this case).  It likes to
   remove empty directories.  Kind of a pain.  I remove with
   a script.  Roughly:
       for file in `(cd $PACKAGE;find * -type f)`
           then check for /usr/local/$file and remove it.

Other options:
   Solaris makes a stab at it with the pkg* stuff.  RPM is interesting
   (and makes installs by neophytes possible and is multiplatform now).

   Depot and such work on a large scale, distributed stuff. requires
   a database (as to RPM and pkg*).  It's been a topic of many
   Usenix papers.




> >  Why not just point users at

> >  /opt/myapp and do

> >  ln -s /opt/myapp-12.3.4 /opt/myapp

> >  ls -1d /opt/myapp then shows

> >  /opt/myapp  -> /opt/myapp-12.3.4

> >  and all the directories underneath point to the right place

> >  /opt/myapp/bin = /opt/myapp-12.3.4/bin
> >  /opt/myapp/lib = /opt/myapp-12.3.4/lib

> >  etc.

> >  Then just do

> >  rm /opt/myapp
> >  ln -s /opt/myapp-12.3.5 /opt/myapp

> >  to upgrade..

> The reason why not is doing the method you describe every application is in
> separate directory.  Distrib allows it that all the xemacs, myapp, emacs, gcc
> files all be in /usr/local/bin and all the man pages are in /usr/local/man
> for all of those applications.  So does not need a very large path.  When you
> are considering 40+ packages that gets very substantial.  And many applications
> like gzip or less are considered default by users.  So in /usr/local/bin
> you have.  Lets you have the advantages of one locations where users can go
> for utilities and man pages without having to look for the directory
> containing the application.

> /usr/local/bin/
> /usr/local/bin/less -> /opt/less-3.21/bin/less
> /usr/local/bin/ssh -> /opt/ssh-1.2.21/bin/ssh
> /usr/local/bin/ssh-kegen -> /opt/ssh-1.2.21/bin/ssh-keygen
> /usr/local/bin/xemacs -> /opt/xemacs-19.14/bin/xemacs
> /usr/local/bin/ispell -> /opt/ispell-3.1/bin/ispell

> Then the you have a similar collection in /usr/local/man

 
 
 

distrib a system for software distribution - an idea for software distribution

Post by Pat Wils » Thu, 08 Jan 1998 04:00:00


Interesting.  You might also want to check out some of the papers
on similar systems that have been presented at LISA conferences -
I'll call your attention to the papers in the "Software Distribution #2"
session of LISA X (1996) in particular.  See
        http://www.usenix.org/publications/library/proceedings/lisa96/

--
Pat Wilson

 
 
 

distrib a system for software distribution - an idea for software distribution

Post by Robin Slomkows » Thu, 08 Jan 1998 04:00:00




>[Remove the nospam from my address to reply.]

stow is very cool and does handle minimizing sym links better, if I
had seen it when I first wrote distrib I never would have written it.
But I did so I thought I would tell some of its differces and let anyone
else who wants to use it do so.  More people should use one of these
systems it really helps keep your stuff straightened out.  Especially on
free UNIX's where you have installed all sorts of libs that affect your
system.

distrib disadvantages over stow:

        not as good debugging messages

        does not have low symbolic link count

distrib advantages over stow:

        removes mode works pretty well
                and it only removes links that are to the source files.
                this should make .stow files unnesecary
                This is purely because it doesn't deal with folded
                directories.

        easily lets you overlay a new version of software without
        removeing the first one.  WILL overwrite existing symbolic
        links, but not real files.

        nice simple syntax for arbitrary locations. ( not a big deal )
        distrib assumes cwd as source unless you specify one.  Though
        you always need to specify a destination.  And its concept is
        more based on files than packages.

Quote:>Moreover:
> - I can REMOVE a package's links (stow -d $PACKAGE)
> - It will links a directory when it's unique to the package; eg.
>   /usr/local/man/man2 might be a link to
>../.Packages/rdist-6.1.3/man/man2
>   if rdist had the only man2 pages (and is, here).
>   This directory link will only be "exploded" (made a directory
>   and each file inside made a link if another package had files in
>   "$PACKAGE/man/man2/"
> - You can tell it to link into anywhere; "../.." is just the default.
> - Mostly, I can just tar up a package, move it to a new machine,
>   untar it and stow it.
> - So what is "amplot"?  (I never found "sq" again), well let's look:
>              amplot -> ../.Packages/amanda-2.4.0b4/sbin/amplot
>   I know the version because of my (chosen) naming scheme.

>It's easy (really easy) to use, you don't have to commit to it
>(it will manage just a couple packages if you want to play with
>it.  Shove some files into /tmp/testme/PACKAGE/ and see it link
>them into /tmp/testme.  No privs.  One scripts.  Really handy
>and lightweight.

>Drawbacks:
> - Some people HATE sym links.  I like them more than
>   hoping a state database is in good shape (ala depot).
> - Symlinks are slow over NFS - they require a number (3)
>   of lookups compared to a file or hard link (a file).
>   Not really a problem for me here.
> - It's algorithm for removing a package seems to search the
>   tree just above (/usr/local in this case).  It likes to
>   remove empty directories.  Kind of a pain.  I remove with
>   a script.  Roughly:
>       for file in `(cd $PACKAGE;find * -type f)`
>           then check for /usr/local/$file and remove it.

 
 
 

distrib a system for software distribution - an idea for software distribution

Post by Karsten Thygese » Sun, 25 Jan 1998 04:00:00


Robin> The Distrib System

Robin> This article is to discuss a method of distributing software
Robin> for a small to moderate sized organizations to keep your
Robin> software versions under control.

Robin> The core idea is that software should be in discrete
Robin> identifiable bundles, that can be identified by version, yet
Robin> are still convenient to add to user paths and easy to find
Robin> current version of software.  It is furthermore important that
Robin> multiple version can co-exist on a system without interfering
Robin> with each other.

You should also have a look at our "pack" system - we have more than
18GB software installed in this system and have been using it on 15-20
sites for more than 5 years...

All software is installed like

/pack/emacs-20.2
/pack/emacs-19.34

where /pack/emacs is a link to the current default version (andled by
either links or automounter)

All curent default releases is collected in a "/usr/local" like
directory (we call it /coll/local and /coll/beta etc...).

We use either the depot software or our own (much faster) system
written i Python.

We even distribute many MB public domain software packages precompiled
for both Solaris/SPARC and Solaris/x86.

Have a look at http://sunsite.auc.dk/pack for more information - there
is also a mailinglist, where questions and request for software can be
made!

Best,
Karsten.

--
M.Sc.E.E, Sys/Net-administrator, BOFH, Aalborg University, Denmark
http://www.kom.auc.dk/~karthy/ for more information.
SunSITE Denmark Manager (http://sunsite.auc.dk/)
# $Id: .signature,v 1.1 1997/06/18 08:30:00 karthy Exp $