Slashdot Mirror
Manage Packages Using Stow
dW writes "This article is about Stow, a software installation management utility for Linux that offers a number of advantages over the tried-and-true Red Hat and Debian package management systems. With Stow, you can package applications in standard tar files and keep application binaries logically arranged for easy access."
Whilst this is some way towards making Linux more user friendly (and ultimately gaining acceptance on the corporate desktop), what are the chances of anything being done about the crazy directory layout of a *nix system?
If the answer is nothing, then a suitable GUI for Linux that has the objective to gain corporate desktop acceptance really has to isolate the [l]user from this - i.e. with something like "My Documents".
I like using Linux, but even as a seasoned IT pro, the directory structure and "what goes where" of a *nix system still bugs me.
One of the reasons I switched from Redhat 8.1 / 7.3 to Gentoo Linux (Beta) was the amazing Emerge package management tool. It combines simple Tar based package files with cool scripts called eBuilds, that automagically fetch and compile all the components I need.
Of course Gentoo is not for everybody... it takes longer to install than Debian (and that is before you have compiled the entire OS from scratch), but for those who are interested in that sort of thing it can be a refreshing alternative.
The article does not mention anything about dependencies. In my opinion dependencies are almost as important as keeping track of which file belongs to what application. Maybe they should do some more homework and take a look at Gentoo's Portagepackaging system. This system not only compiles a tar/tar.gz/tar.bz2 package, but also retrieves the needed packages (including the dependencies) from their homepages.
You know it makes sense, a little reminder from jointm1k.
I've got some experience with Debian's package management system, and while hard to use for a novice and somewhat complex there is one great benefit: conflict and dependency handling.
Based on the article I didn't quite understand if Stow provides similar services. There were some hints on this, but could someone with experience shed some light on the subject?
.: Max Romantschuk
This has about as much flexibility as distributing binaries in a tarball. You can't include installation/uninstallation scripts (what if my application needs to install a cron job?). Everything is forced into /usr/local/stow/PACKAGEDIR and a mess of symbolic links are used to bump everything into the corresponding bin, lib, include, whatever directories. While it may be easier for the software to manage, it creates countless unnecessary files on your drive.
I don't see the benefit.
In windows, I double-click setup.exe, a GUI pops up, I pick the destination and off it goes. Why can't someone make something like this for Linux? It would greatly improve the user experience in Linux. Instead of having to edit 8 configuration files, the user just starts setup.sh or something and the setup asks questions. This is why I like apt-get - one line setup. But every time I download something that's not part of Debian it turn into a horrible experience I wish I would have never had.
1. Stow requires you configure all the packages into their own directory, which will cause problems with Gnome and KDE. Some packages are easy to configure into one directory, eg. /usr/local, and then install into another, eg. /usr/local/stow/packagename. Others, not so much...
2. Stow has a serious bug in the way it handles directories. If only one package touches a certain directory, it simply creates a symlink to the directory. And then if another package puts something there, it then removes the symlink and does the normal thing. This is a good idea, however, Stow borks this up sometimes, which is bad.
If you're interested, there's a program similar to stow, called srcpkg, at tempestgames.com/ryan. Yes, I wrote it, sorry for the blatant plug. I thought it relevent because I wrote it after experiencing said problems with Stow. FYI, I use srcpkg to manage all the non-system software on my machine, including Gnome, KDE, mplayer, ogg, SDL, and a very large number of other libs and programs.
There's also a number of similar programs on freshmeat. They're all tailored to slightly different needs, but they're all generally better than Stow.
Sticking feathers up your butt does not make you a chicken - Tyler Durden
The reason is readily apparent. There is no clean, high-level way to specify installation details to make. Almost always "make install" invokes a messy ad hoc jumble of Bourne shell commands. Make has its own variables. Bourne shell has its variables. You end up double escaping all kinds of items and end up with $$Variables and a plethora of back ticks. The consequence is that install details in a make file tend to look like Perl's uglier cousin. Throw in line extension by escaping line ends with a reverse solidus, and you have the makings of a maintenance nightmare. Try previewing "make install" with "make -n". Not too helpful is it?
How to fix it? I don't know. Perhaps if all Unix vendors could agree on an "installation specification language" -- ISL. Then each vendor's "make" program could incorporate an interperetter for ISL. Other programs like Linux RPM could benefit for this too and incorporate an ISL interpreter because RPM installation specifications are only slightly better than plain Bourne shell (although definitely a step in the right direction).
I think more people should take a look at tclkit (http://www.equi4.com/tclkit) and the concept of starkits (http://www.equi4.com/starkit). This is a great concept where an application is delivered as one self-contained file (compressed, with an internal virtual file-system). This gets rid of the problem of "installation" all together.
Very cool stuff.
A quote from http://cr.yp.to/slashpackage/finding.html
/etc/csh.cshrc and /dev/log and /bin/sh and many other files. The reason that all those filenames are listed in /etc/csh.conf is so that they can be changed.
/etc/csh.conf itself. That's why csh looks for the /etc/csh.conf filename in a hashed /etc/registry.db file.
/etc/registry.db. That's why the registry filename is listed in a COMPILEDFREGISTRY environment variable.
/etc/fregistry_variable_name.txt.
/etc/fregistry_variable_name.txt? You fool! We have billions of programs that /etc/fregistry_variable_name.txt at the top of main(). Everything _else_ has to be configurable, obviously, but /etc/fregistry_variable_name.txt isn't going anywhere.
``Software should never ever assume it knows where to get files from,'' someone once wrote. (He says I'm taking his quote out of context, so I won't identify him here.)
Here was my sarcastic response:
Yes, that's a very important principle!
Let's take, for example, csh, which uses
Now, some people want to move
Of course, on some machines, we need to move
There's still the possibility of conflict with previous uses of the COMPILEDFREGISTRY variable. That's why the name of that variable is listed in
You say you want to move
It is good to be able to use independent directories for applications that are installed at the site (i.e. not part of the distribution.) And RPM can accomodate such independent directories as well. Within the independent tree, the applications should standardize the directory structure just like in unix: ./etc etc.
./bin directory can be used to keep the subscriptions to bin directories of subscribed packages.
Then, putting symbolic links in various directories is bad idea. Instead, users could explicitly 'subscribe' to the directories. A special, user specific
Bad thing about RPM is that it uses a centralized DB for tracking dependencies, which can't be manupulated by hand. Instead, it could evolve to use 1. open format based on XML 2. Put the dependencies as part of independent directory tree of the package.
In most cases, it is sufficient that dependencies be evaluated dynamically. After all, sysads know what they are doing.
-vgk
And what would that be? Guess what things are installed and try to remove them properly? This is a tool for a system manager to keep track of what's installed on a system--windows has no advantage whatsoever for that. (Multiple programs overwriting the same dll, registry entries spreading everywhere, lack of seperation of users in many programs, etc., mean that there's a lot of work to do in windows.)
If you don't know and don't care, wouldn't it be easier to just not post?
And has used it from the very beginning. So you could start recommending it right now ;-).
Checkinstall was initially developed in the time when makepkg had no command line options to answer the questions about symlinks and permissions, so Checkinstall uses by default a makepkg from Slackware 7.1 which was hacked to not ask those questions and instead assume specific answers to them. And it has been updated with the changes and patches introduced in Slackware 8.0 and 8.1 (i.e. the "slack-desc" file with handy ruler and all)
Aditinally, you can still use Slackware's native makepkg if you set the MAKEPKG variable in checkinstall.