Slashdot Mirror

There is a package management system called encap that does that automagically. There is a program called "epkg" that implements it very well.

I do

cd /usr/local/src/package-n.mm
./configure --prefix=/usr/local/encap/package-n.mm
make
sudo bash
make install
cd /usr/local/encap
epkg -s . -t .. -i package-n.mm
^D

Epkg also helps maintain /usr/local, and can maintain a /usr/local for binaries it can't run. I have sites with Solaris servers and mixed Solaris/Linux clients, and use the Solaris version of epkg to help maintain both trees.

I think it's the most unixy way to do package management.

The biggest problem here is that *nix is still very much command-line driven, and therefore the PATH environment variable comes into play. Desktop environments can alleviate that by providing good program launchers (menus or otherwise), but you're still going to want to use the command line for many things.

There is a solution, however. Encap is a system where applications all install into their own directories (say, /usr/local/encap/yourapp-version.number), and are linked into the "standard" places so that you don't have to muck with your PATH. For software using autoconf, simply use the --prefix option when running configure and build away. When you make install, everything is put into the app-specific directory, with bin, lib, share, etc directories underneath that. Afterwards, use epkg to link everything up. The only drawback is that there's not much in the way of software pre-packaged for encap, so if you're into using RPM or apt, encap won't help. If you like building everything from sources but don't run something like Gentoo or a BSD with ports, encap is a very good thing indeed.

There are other linkage systems similar to encap, but encap comes from my alma mater so I'm biased. When I was there, all of the software on all of the unix clusters (the engineering and CS departments had their own separate systems, consisting of many different workstations all using a shared DFS for applications and such) used encap for software management. From a management perspective, it gives you a lot of flexibility when upgrading. Installing a new version of a piece of software does not require removing the old version, so you can keep them side-by-side until you're sure there'll be no problems with the new version.

Here.

It's a simple idea, but works well. The FAQ there will explain it all.

In my experience doing a partial upgrade will only screw up the installation anyway.

That's because all of the binaries are mixed in together. If you kept all of package foo's files in its own directory, then separate them again by version, you don't have to worry about dicking some package over by installing a new package. All you have to worry about then is removing packages, and only then because of dependencies (which the package manager should be keeping track of for you). That said, I don't like GoboLinux's way of breaking the packages apart. The majority of the software for Linux (and the BSDs too, probably) comes as a discrete unit, either as a binary package or a source package. The division on disk should be by those discrete units.

For example, suppose I have package ``foo.'' The top level directory for all of my packages is /usr/pkg. Foo's directory is /usr/pkg/foo, and each version of foo gets its own directory as well: /usr/pkg/foo/foo-2.1.3. Under that directory, the expected directories exist, namely bin, lib, info, man, share, and so on. Now there's no possibility of mixing packages up. There's no difficulty installing foo-2.1.4 now, because it goes into a totally separate directory. If I've got one working computer than can't afford to be broken, this system has even more advantages. If foo-2.1.4 is borked somehow (maybe due to a wrong compiliation switch, etc), then I can uninstall it by deleting its directory. Best of all, foo-2.1.3 is still there. Lastly, if you hate this arrangement, it's easier to merge the directories than it is to separate the files back out.

Gobo maintains compatibility by symlinking all those files back into the standard Unix tree. A package manager called Encap works similarly. I dislike the symlink approach, because it uses up twice the number of inodes in symlinks, on top of what gets used up by having each package have its own directories. For the most part, it's possible to keep track of things with environment variables, but when your $MANPATH variable gets long enough, there are noticeable delays while it searches the path. The same goes for $PATH, but shells will cache a program's location, so it's not that big of a deal (and even so, it'd be worth it just to keep the binaries separate). DragonflyBSD is planning to do a filesysetm overlay to handle this (if I understand their documentation correctly). If everything works out right, they'll have the best of both worlds.

The problem with all of this is that it's entirely different from the normal Unix layout. Most existing tools expect your include files to be in /usr/include, your libraries to be in /lib /usr/lib or /usr/local/lib, and deviation from that causes a lot of trouble. When I install a library, it doesn't necessarily delete previous versions of that library, but it'll change the main symlink to that library to be the new version (and reinstalling an older version will probably change the symlink again). Another problem is that autoconf doesn't list a program's dependencies. If you have a library installed in an odd location, you're informed of it as part of an error. It would be trivial to just list the dependencies as part of autoconf's operation. Basically, if something like this were done on a large scale, it'd require a LOT of changes in preexisting tools.

There's certainly a need for change, though. The majority of Unix-like installations are people's home PC installs. Often, this means that Joe User has one computer that he can't afford to bork over. If installing one program ate another program's files, then Joe User is in trouble. Think about what happens if he's trying to upgrade gcc, compiling everything from source? If the install doesn't go just right, then he just overwrote his working C compiler.

You're free to have a low opinion of Solaris, but you really should be more informed about it first. I'm not trolling or flaming, just hear me out before you mod me down.

Lacking GNU stuff in the default install may be a killer for you, but it really depends on your perspective. That is changing, anyway - solaris 9 has assorted gnu stuff included in /usr/sfw (if you install it), and I'm sure solaris 10 will have more. I really don't find it to be that big of a deal, because at my site I end up custom-building so much stuff anyway that it hardly matters.

I have no idea what you mean about commandline editing. Solaris comes with bash, and I bet that's what you use elsewhere.

The package format is old, and it will remain that way. It works the same now as it did ten years ago, and for many people that is a Good Thing. Anyhow, you don't need to make your own SysV packages. Make use of something like Encap to manage your /usr/local tree and keep your site-local packages away from the system package manager.

Patching isn't as hard as you make it out to be either. You could just wget ftp://sunsolve.sun.com/pub/patches/9_Recommended.z ip and run the install script in there to pick up any security fixes. Personally, I use a cron job to download that once a day, and then I run Superglue, which is just a shell script, to figure out which patches I need and install them out of an nfs share. It's simple, it works. Note that I don't cron the installation of packages, just downloading them. Cronned patch installation makes me nervous.

The installer sucks. Oh btw, DO NOT use the "install" cd. Boot "disc 1" and throw away the install disc. Seriously. Also, you really should not be using the installer if you have more than one or two systems. Set up a Jumpstart and net-install your machines. It really isn't difficult. One again, simple enough and it works.

Your ultra5 sucks, sorry to say it. Those were just lame machines. There is a reason they cost like $90 now: they suck. They can be made more useful with the addition of a $40 scsi card from ebay; that onboard cmd640 ide controller is godawful. Fwiw, I had an ultra5/360 with 256mb of ram and a pair of scsi drives (no goddamn IDE) withstand a full force slashdotting with ease. If you want a cheap sun machine that sucks less, find yourself an ultra2 2x300 with creator3d. Dual cpu, lots of ram slots that take normal sun ram, scsi storage. Should run you $300 or less. Sbus cards are cheap nowadays, too.

Solaris does support 24bit color depth on that machine; you just have to set it using fbconfig. I have no clue why they don't support 16bpp, and you're right, it is retarded.

And yeah, CDE sucks. Install Gnome. It comes with solaris 9 and it will be the default desktop in solaris 10.

Finally... I just don't bother using solaris as a desktop system. Almost all the workstations I run are Linux or MacOS. But damn, Solaris makes a good server OS.

Files created by a "make install" usually don't have any way to cleanly remove or upgrade them; you can upgrade by installing a new version over the old, but if the old version included any files that were removed in the new version, you still have that cruft sitting around.

--prefix=/usr/local/encap/package-version

Whoever thought this was new has obviously never heard of encaps. Basically the same idea, but it's been around for about 5 years longer. Look at www.encap.org for starters. (I'm not going to write a lot since nobody will read this anyway.)

epkg is a related utility that I found very useful...

I think this is actually a bad idea. I like the fact in linux or freebsd all the config files for all programs are in /etc or /usr/local/etc. This allows me to check the /etc into cvs and be able to revert my system into a known good state.

I also like the convention of putting all data in /var or /home which most linux distros do. This means I can devise backup strategies which allow me to back up the files in those directories more often then the files in /bin or /sbin.

Finally I like being able to set immutable flag on the entire /sbin directory and checking for permissions by doing a simple ls -la.

Instead of putting everything into one directory they should have followed the example of encap

I use and like http://www.encap.org/

That's the way most packages should be installed anyway, even with rpm and deb and such. Then create symlinks from places like /usr/bin into that /opt directory. Removal is a simple 'find' operation to get the symlinks, then remove the directory under /opt. Like Encap.

System-level packages don't work so well with this format, of course, and if you need to make some partitions read-only you can run into some issues. Hey, nothing's perfect. But for non-system stuff...

Dude. *DO NOT* use patchpro. It is a complete piece of shit! Instead, do one of two things:

A) periodically download "rec+sec" patch bundles from sunsolve.sun.com and install them

B) Or, do what I do and run your own superglue patch server. This is just an nfs share with the patch collection unzipped into it, along with a cron job that updates it once a day on the server. Truely trivial to manage.

Info on superglue (written about my particular superglue installation, which you can use if you want, but I wouldn't trust some random dude to distribute OS patches!): http://www.acm.uiuc.edu/wiki/space/Superglue

To get the superglue script, read through that page, mount my nfs share, and get the superglue script. It's just a shell script. It is installed as an encap package (encap.org), so you can copy that and install it yourself.

Seriously, try it out. It's absolutely wonderful. By far the best way I've found to keep your system from accumulating too much cruft (well, it won't stop the accumulation, but it will make it trivially easy to get rid of later). I've only used Encap, but it's way way cool. When you compile a program, use "--prefix=/usr/local/encap/program-1.0" with the configure script, and then you'll have /usr/local/encap/program-1.0/bin, /usr/local/encap/program-1.0/share, etc . . . Then you run "epkg -i program" and it'll install all the symlinks correctly into /usr/local the way you'd expect. Then you can remove packages, upgrade, etc, etc, etc. Very fun.

I agree entirely, but have one thing to add.

Slackware users don't want a packaging system for everyday use.

Try encap. Not really a traditional package manager, but works very well with source.

Basically, instead of "make install", you do "make prefix=/usr/local/encap/(programname-version) install", type "epkg /usr/local/encap/(program-version)", and it symlinks everything to the appropriate /usr/local locations automatically, deleting previous symlinks from old versions beforehand. Yes, you could do symlinks by hand, but that's a pain if the program uses a few hundred different files that can take too much time. Epkg does it in a few seconds.

New version of, say, your favourite email client is misbehaving? "epkg -r /usr/local/encap/(programname-version)" deletes the symlinks. Easy as pie. I love the encap concept since I try lots of bleeding-edge CVS versions of programs. If a new version sucks, I can go back to an older, working version with just a few commands. I don't have to recompile old versions over again.

From the article:

/usr/local, /opt

These are obsolete folders. When UNIX didn't have a package system (like RPM), sysadmins needed to separate an optional (or local) application from the main OS. These were the directories used for that.

I understand that this is directly from the FHS, and not some evil concoction from the mind of the author, but dammit, I think it's wrong. Perhaps /usr/local is obsolete with respect to package managers, and that makes some sense (because the package manager should handle proper management of placed files, though in practice that's not always the case), but as long as open source is around, there will always be software that is compiled rather than installed through a package manager. There will also always be applications that are not distributed in your package format of choice (as long as there is more than one package management system, this will always hold true). In these cases, it's still a good idea to keep around /usr/local and /opt. Personally, I'll have /usr/local on my systems for a long time to come, because I prefer to use the Encap management system.