NO MORE UPDATES TO THIS PAGE PLEASE. SUBMIT ALL FUTURE COMMENTS TO

23.1.2 pg 490

Note that storing software repository files locally may have impact on backup policies; either they will need to be tuned to avoid backing up the local repositories (after all, they can be rebuilt from the archive store) or else you have to plan on handling additional data storage requirements.

23.1.3 pg 491

Note wrapper scripts have technical problems as well; eg #!/sw/bin/perl will not work if /sw/bin/perl is itself a shell script (eg starting #!/bin/sh). Not that I've had this problem here, oh no...

23.1.3 pg 492

A good software repository can also track USAGE of software from the repository. That might be "icing", however.

23.1.4 pg 492

Recognise that your company may already have a legacy repository system, but that the company requirements may have changed or the existing solution hasn't scaled properly.

23.1.6 pg 495

Another way of handling other OS's is to integrate them into the main tree in a neater fashion. eg you could have

/sw/perl-6/$OS/bin
/sw/perl-6/man
/sw/perl-6/etc

Obviously the different OS builds will have the same manual pages, so why replicate? Any differences in /etc files could be handled by the "bounce" technique. This solution actually allows you to have Solaris 8, Solaris 9, HPUX, AIX etc etc all together, which makes it easier to track versions (oh, look a security hole in package blah version 4; how many places do I have to hunt for it to remove it? With this solution... 1 place!). If the software build is identical between platforms (eg Solaris 8, Solaris 9) then a simple symlink can be made between the $OS directories. This also saves disk space!

-- StephenHarris - 24 Aug 2006