1833016 Members
2262 Online
110048 Solutions
New Discussion

Depot files

 
Joseph Geniec
New Member

Depot files

My question is: Why does HP use them? I don't seem to understand what good they are, or why they are necessary.

They are extremely frustrating to use, especially if a user happens to not be root, but wants to try out a piece of software.

What is wrong with .tar.gz?
9 REPLIES 9
Geoff Wild
Honored Contributor

Re: Depot files

depot files give better software management.

man swlist

If you use plain tar files or compile from source, then how do you tell what is installed?

depots is the way HP chose to manage this and it works quite well.

With depots, you can uninstall software from HP-UX - if I was to compile say, samba on my own, it would be very difficult to uninstall - I would have to know every file that the "make install" put on my system....

Rgds...Geoff
Proverbs 3:5,6 Trust in the Lord with all your heart and lean not on your own understanding; in all your ways acknowledge him, and he will make all your paths straight.
KapilRaj
Honored Contributor

Re: Depot files

better management ... and thats the best advantage as geoff said. Any operating system has it i suppose.

HP has .depot ,AIX has something called .bff etc etc

Kaps
Nothing is impossible
Sridhar Bhaskarla
Honored Contributor

Re: Depot files

Hi Joseph,

I like the depot files. They are pretty good to keep track of the softwares on the boxes which is a primary responsiblity of a systems administrator. Problem with tar files (and other types of installation practices) is that there is no centralized database maintained and one has to manually keep track of what's installed on the server.

I agree that it may be frustating for the user. If it is a simple depot file, you can actually untar it and it will create a directory structure with the files under it. However, some softwares may tend to go into system directories like /opt,/var etc., and may not run if they are simply untar'ed in other directories. For those softwares, you would need to take the help from your systems administrator.

-Sri
You may be disappointed if you fail, but you are doomed if you don't try
Cesare Salvioni
Trusted Contributor

Re: Depot files

I agree with all previous answer,
just adding that depot files and SD in general is very usefull also for:

1. checking dependencies (when you install something, the fileset contains info checked against installed software to insure the package will be able to run)
2. avoid overwriting of package already installed with older version
3. verifying that installed package are still completed, files have not been deleted, have not changed checksum ...
4. patches managment more flexible and sure (you can uninstall a package and go back to a previous state)

last point: what you see as a cons in my opinion is a pro: normal users CANNOT install products in system directories eventually arming the system, only root can change contents of /usr/bin, /etc .... (think about how many problem in WINDOWS when you install something that change a DLL and make something else not working !!!!)

Also think that
1. when you package a product with SD it is possible to let the installer change the target and so install it in some different place from the original (if the package let it)
2. the depot file is, after all, a tar file with some control and script file, so u can always untar it somewhere and try to make it works, the only thing is that if u r not root u can't use the system directories

Last and i stop, as someone already told every serious unix as something similar, what's the difference between SD and RPM from redhat?

Hope this helps
Michael Tully
Honored Contributor

Re: Depot files

The question would be:
How could you possibly manage a system without depot files ...

Advantages:
You know what products and filesets are on your system and the version.
You know what patches you have installed.
One easy command (swlist) to list all levels.

Disadvantages:
???

As far as trying out software is concerned, well where possible these should be confined to a test server.
Anyone for a Mutiny ?
Bharat Katkar
Honored Contributor

Re: Depot files

Hi There,
Just to add something:

SD-UX maintains a Database called IPD, Installed Product Database which help you keep track of all installed software. You can always Roll Back to the previous version, upgrade to newer one with the help of interactive SD-UX User Friendly Menus. It will guide you properly with the dependencies and required depots, filesets for a particular product along with the versions name. Unless and untill you are familiar with the SWINSTALl you won't be able to understand it's capabilities and thereby its advantages.
It is more helpfull in keeping track of PATCHES installed on the System.

Regards,
You need to know a lot to actually know how little you know
Bruno Ganino
Honored Contributor

Re: Depot files

Bharat Katkar
Honored Contributor

Re: Depot files

Bill Hassell
Honored Contributor

Re: Depot files

If you have tried managing someone else's system where most of the applications were installed with tarballs or similar, the answer is very simple. There are no rules at all in a tarball. It's a load-and-pray scenario. You un-tar an application and then try to guess where everything went. Some tarballs create their own application structure in /usr/local, others create a /something directory which crashes the system by filling up /. And virtually no tarball install package verifies dependencies and revision levels for related files and programs. tar can silently wipe out existing programs and disable or cripple other applications.

Now to be fair, a well-written install process (tar into a tmep directory, interact with root for further instructions, etc) can bypass most of these issues. I have yet to see one of these, even in software that cost $30,000. I NEVER install a tarball without getting a table of contents and analyzing where everything will be located. And if it is wrong, I complain to the author and if necessary, use a chroot environment to keep the tarball jailed in /var/tmp until I can straighten everything out.

Look at the man page for sd (man 4 sd and also man 5 sd) and you'll see that Software Distributor is an extremely sophisticated packaging system that prevents huge mistakes like installing 64bit patches on a 32bit system, or loading an application on a PA-RISC system when the executables were compiled for Itanium, or simply picking the right patches for the current system.

As far as installing software by any user, most IT administrators and directors are tearing their hair out (I can attest to this!) concerning users that put any old package on their system and then trying to figure out what happened. This is rampant in the PC world. email viruses are passe' now. The latest threats come from popups and click-here buttons that install spyware and malware.


Bill Hassell, sysadmin