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."
"My Documents"? Ever heard of /home/$username?
Why is that when companies releases something, a GNU friendly user always get the creeps! This is no exception. (This is released under GPL but anyway!)
Let me quote RMS: "Note the distinct difference between free as in freedom and open source as in buzzword"
Girls are strange. They don't come with a man page.
-- Michael Mattsson
The UNIX way of putting applications is well thought out, matured and perfectly fine. Needlessly playing around with it is likely to cause more problems than it solves.
Yes, the package management scene on Linux sucks right now. But it is because of dependency management, and has nothing to do with all the files of an application in a nice folder.
So, I took my Chevy Cavalier to the dealer this morning to get brake work done. He strongly recommended that instead of fixing the Cavalier, I should convert to Gentoo. It apparently solves all of my problems.
...well, anything. Examples:
Sorry, but I get tired of people always saying this type of thing about
Q: "I need help with my sendmail configuration." A: "Use postfix/qmail/etc."
Q: "How do I get <some device> working under Linux?" A: "Use FreeBSD."
Q: "Take a look at this package management system." A: "Switch your distribution!"
All of these have better, usable answers that actually answer the question.
I don't mean to flame or troll, but responses like this are counterproductive and annoying.
--RJ
A few reasons. Firstly, these programs are tremendously complex under the hood. Almost all generic ones (even light ones like NSIS) include their own scripting language. InstallShield 6 and up has used DCOM to provide remote procedure calls between the install script and the engine (ikernel.exe if you've ever wondered what that is). They do a lot of messing around under the hood in order to make things just work.
Even then, they are too primitive for Linux. For instance, they have only basic concepts of dependancies. The lack of proper dependancy management almost brought Windows to its knees in the mid-nineties. Simply packaging every dependancy inside one self-extracting archive is simply not possible on Linux in any scalable fashion, so we have to build dependancy resolvers like apt. Windows installers tend to be GUI only. And so on.
Now, systems like apt are pretty cool. When they work, they work really well. The problem is, that they tend to be built by distro projects, and then they are relatively tied to that distro. Apt as used on Debian for instance, is not the same as apt4rpm. URPMI is Mandrake, and emerge is basically tied to Gentoo, though I'm sure it could be generalised.
So, the real solution is not to build Windows style setup.exe files. The real solution is to make something like apt, but that can be easily used by everybody, so you rarely if ever come across software that doesn't use it.
There are two approaches to solving that problem. We're trying both at once. The first is to invent a new system, independant of the existing ones. See my sig. The second is to try and standardise key interfaces in a standards body, so that apt/urpmi/emerge and others can interoperate, and so you can plug distro-neutral packages into that framework. See here. Note - most of the activity so far related to that group has been off-list, hopefully there will be action starting in a few days.
That works fine for a few applications. Linux has thousands of applications, and people tend to install hundreds of them (they are free, after all, so why not). Do you want to go through hundreds of GUI installers, and then hundreds of GUI updaters? I don't.
Why can't someone make something like this for Linux?
There are interactive installers for Linux packages, but they are usually a nuisance compared to a normal package.
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.
Well, then don't install non-Debian packages. After all, there are plenty of Windows programs that come with horrible installers. As a Debian user, think of non-Debian packages as "programs that come with horrible installers", and then decide whether they are worth the trouble. (Note that you can usually import packages reasonably well via "alien".)
The package system you get with Debian (or RedHat, for that matter) is already so much better than anything you get for Windows that it isn't funny. If Linux developers adopted the equivalent of setup.exe more widely, that be a real blow to Linux.
Something like SCONs perhaps, although I'm not sure python is the best language for this. Although it's possible, easy even, to write really ugly bash, it's a very good language for filing system manipulations, which is a large part of build management. There was another build system based on bash that was a LOT easier than autotools, but I can't remember what it was called! :(
Why is a tar file any more 'simple' than an RPM or Debian package? If you are just storing a bunch of files, then yes. But what about metadata? That is, the information on dependencies (what libraries the package needs), where to get the source code, who the packager was, which version of the software these files represent, whether this packge conflicts with any other packages that might be installed, and all the other things that a decent package manager keeps track of automatically so you don't have to check them by hand, or get nasty surprises when you've installed a package and only later find a necessary library is the wrong version.
If you use tar files then you'd need to have an extra metadata file inside storing this information: then you need to decide a format for that file and write a tool to parse it. And you've then reinvented rpm or dpkg, only with the spurious 'improvement' that people on other systems can unpack the archive if they have tar installed. As if anyone running a different system would need to unpack someone else's binary packages.
Perhaps you could argue it would have been better for rpm to be based around tar.gz format, with the package details stored in the tarball as a script of some kind. But then it would become much slower to query a large directory of packages. Maybe that is important, maybe not. Also you have digital signatures to worry about, it's not clear how to do those with a tar archive (unless you have one tarball containing another tarball plus its PGP signature). Perhaps things could have been done differently, but the mere fact that the rpm and dpkg developers chose to make their own format rather than use tar is not an excuse for committing much more serious wheel-reinvention in making a kewl Yet Another packaging format.
I'm not meaning to knock Gentoo here, that distribution really does do something new (building everything from source), and they perhaps had good reason to make a new packaging format. (Although it might have been worthwhile to investigate whether building from source could fit in with rpm or Debian source packages.) And Slackware has used tgz packages since the beginning, and doesn't seem that bothered about automatically tracking dependencies.
But for most uses, I just don't see why 'simple packaging with tar' is particularly simple in the long run or much of an advantage. It sounds like those Freshmeat projects which say 'this is yet another MP3 player but it has the advantage that it doesn't use GTK or Qt but implements its own user interface code instead'.
-- Ed Avis ed@membled.com
That's why we have/need dep resolvers like apt. I rarely, if ever, hear Debian users complaining that dependancies are too complex. They don't need to care.
I was a build engineer for a large telecom company who had a commercial Windows product which used InstallShield. I wrote the installer for that product (twice). I've been using Linux since 1994 in various ways. I know InstallShield and I know Linux, and trust me, you don't want IS for Linux, no matter how much you think you do. People are better of sticking to whatever package management system comes with their distribution than pining away for something like InstallShield.
Having a single point of installation management is far superior (even with dependancy checking issues, like sometimes happens with RPM) than leaving it up to the software maintainers. Windows should have orginally shipped with such a centralized system IMO. Now they force software developers to jump through hoops (which cost money, incidentally) in order to get a sticker on their box saying their software was "Designed for Windows". Barring that "certification" a person can do whatever the hell they want in an installer, and your system can become an unorganized mess in very short order.
Even now on this Win2K machine I've got more than a dozen apps (most of which are commercially released) that aren't listed in the Add/Remove Programs applet. If I install something via RPM or apt, that can't happen. I just have to hope that one of those Win32 apps doesn't conflict with something else down the road, since there's no way to remove them programmatically. That's a critical flaw of Windows' installation setup, IMO. Just one that happens to come to mind, even. I could go on all day...
I admit not knowing about linux, and am doing little to change that.
Your parents must be terribly proud at having imbued in their progeny such an insatiable thirst for knowledge.
-B
Ash and Hickory, straight-grained and true, make excellent bludgeons, dandy for the cudgeling of vegetarians.