Slashdot Mirror
The State of Linux Package Managers
I was pointed over to an editorial that is currently running on freshmeat. The author of the editorial takes issue with the current state of package managers for Linux and proposes a way to fix inadequacies. Here's a sample of the solution: "The solution to the problem seems to be to extend the autoconf
approach to package systems.
This requires providing the necessary tools, standards, and guidelines to
software and/or package authors to
enable a single source package to produce a wide variety of binary packages
for the various platforms and
packaging systems."
Since the disk with my /var partition on it crashed, without a useful backup, I've been using rpm2cpio | cpio -i to install stuff from RPMs. Works like a charm. Doesn't overwrite any newer files, and you can do cpio -t to list the package first if you want. No more package database for me, and I don't have any problems with upgrading from tarballs, etc.
Well, Linux operating systems need to stop pretending that they are "distributions" and start pretending that they are operating systems.
signed,
-- Linux using AC that's never touched BSD in my life
I don't use much Windows shareware, but the last thing I tried to download helpfully overwrote some system DLLs with "new" ones dated from 1996.
The integrity of Windows depends on the behavior of the installers, or some system file protection daemon. That's broken.
Linux's package installation is still rough, and the core libraries have been unstable has hell, but at least the infrastructure to do it right is in place.
Mac users have largely avoided the "DLL Hell" problem that Windows and Linux suffer from (in different ways) because the OS includes very few system librarys (as seperate files, anyway). There's a few for OpenTransport, a few from Microsoft, but most Mac apps are monolithic files.
From what librarys have been deployed on the Mac, there's certainly been DLL hell. Adobe printer libs being incompatible with the Apple ones, installers dropping in System 7.6 libs on on an OS 8+ system, and so on.
I haven't seen OSX, but right now Apple hasn't been doing a very good job on this topic.
I think a new universal package system would be good. I have used rpm and dselect and can say somethings missing.
I want to be able to compile a program and have the package manager catch the outout so I can use it to uninstall the program w/o having to write down the dirs. and do it by hand. Unless (as I said) I am missing something they cannot do this now. Maybe a attribute (-pkg?) added would tell the packager to catch the file list?
Just an idea. Most of the packagers are ok but have little flaws. dselect (haven't used apt yet) is kind of messy and not intuitive, rpm is dumb.
That works OK as long as the program is a standalone application that does not export anything useful to the outside world. As soon as you have subsystems that interface with eachother, or applications that can exchange information with eachother, this approach no longer is that attractive.
- Read only, so that the only way files get added to or removed from the package tree is through the package manager.
- A virtual filesystem (i.e. don't store the directory entries on disk, just use an efficient in-memory algorithm for locating files, etc.)
This would also present something more portable, since you only need 'add-in filesystem' hooks on the system.What's wrong with
make install
Ever heard about the power of scripts?
You invent a meta file format that describes your files, tell
the other developers about it and then you write at most a
script per plattform you want to support that uses such a
meta file to fetche the sources, compile the code, runs the
test cases and builds the right packet for that plattform.
Another way is to implement that feature in the Makefiles.
There are also some ready made software that helps you
with these things, check the ads in Dr Dobbs Journal
or some other trade mag.
there is also gnorpm (rpmdrake is better imho)
We have seen this method on SCO OS5 (whole system was bunch of symlinks to /opt), it was a nightmare, thanks, not anymore.
Well, technically that would not "uninstall" enlightenment. Rather that would just be removing the single binary. There is still a host of other files that get installed when you do 'make install' with enlightenment. Most packages include a 'make uninstall' script that essentially removes all of the files it created at install, as well as directories that it created. That would have been your better option.
Hmm...Good idea...BUT....we'd be using /proc from?)
Plan 9, with it's process-private namespaces, which are admittedly very cool. Maybe what we really need is to evolve linux into an EROS/Linux/Plan 9 hybrid (where do you think linux/sun nicked
Unfortunately, Plan9 is not Open Source.
How about the amiga install system - mandate that all program components go in an ASSIGNed directory eg PPAINT: (I miss assigns...), and have an GUI scripted install tool using a LISP dialect?
It's not a clean uninstall (in my book) if uninstalling it breaks something else that depends on it. So, a good uninstaller needs dependencies.
Some packages may want to make shared libraries available to others, and they need to be in a defined location (or you would end up having a lot of directories with shared libraries, maybe not a bad idea but not the current state of affairs). Also, many packages want to make a program available at a place where it is known to reside so others can find it, e.g. /bin/ls or /usr/sbin/sendmail. Most of this is not a problem when you want to distribute a standalone application, but you will run into trouble when you want to distribute existing parts of the Unix/Linux system using this method.
They also require someone specifically construct them. (Waiting for that latest release of XFree86 or some other shiny new thing? Both Debian and RH have at one time or another lagged behind.)
This is true about as much as "XFree is proprietary because you have to build it from source". I just made two new RPMs today. It took all of 5 minutes. I could make a specfile generating script that created really lame RPMs (they would be packaged and managed but not very smart when it comes to documentation or identification) and would be just as easy as using Stow. But that's not really necessary, since almost anybody who's going to want to make nonexistant RPMs will already have the technical skill to do so (except the people complaining about getting CVS GNOME and KDE and snapshots of X as RPMs; but they should not want RPMs or want the packages at all, since they obviously don't want to use them for their intedend purpose).
The "other Andover sites need hits too" department?!?
friend
.deb vs. .rpm. Without inciting any sort of holy war (if that's even possible), could someone please compare these two styles of package management. Thus far, I'm only used to RPM, but I've seen it fsck up sometimes and have to lose dependencies (maybe i don't know all there is about it yet??)
Also, while you're at it, you may as well explain some deficiencies of the tarball methods too.
Thanks.
Not only that it will say "So do you want to download this off the net?" debian is really just amazing, I'm hoping redhat + mandrake pick this up asap
my guess would be that FreeBSD maintains the system layout, where as all the Linux based operating systems throw their hands in the air, and hope it comes together good enough to make them money. Or, they do a substantial job, or they take it from someone else's layout (ie. Mandrake, Corel, etc). I believe that they'd have to make a standard for layout to do a port system. Please tell me I'm wrong.
why cant Linux take the good install method windows has, and then improve the uninstall, nobody said Linux has to do things the way Windows does. Yes Windows has an excellent way to install crap and Linux doesnt, but Linux has a way to un-install but Windows doesnt who says Linux cant do both best? take the best of both worlds.....
YAH, YAH RPM REALLY SUX0RZ. I DONT UNDURSTAND Y NE1 WOOD UZE IT. ITZ JEZT LIEK TAR.GZ EGGZEPT U HAV 2 DOWNLOAD SOM TOTALE GNU APP 2 EXTRACT YO PHYLES. IMHO, IT IZ RED HATZ LAME AZZ ATTEMPT 2 DOMINATE THA LINUX SCENE. C, IF ALL SCOURCE IZ RPMD, EVER1 HAZ 2 UZE RED HAT. I'LL STILL UZE OPENBSD TILL I DIE THO!
HAPPY TROLL DAY.
LATROZ DATROZ
CEO: TROLL KORP
MEMBER: UNITED COALITION OF TROLLS FOR THE ABOLITION OF MODERATION
FOUNDER: ALLIANCE OF TROLLS AND FIRST POSTERS FOR A KOOLER WORLD
For some reason when I use autoconf it causes strong and prolonged erection. It is a big discomform, as sometimes it gets badly pinched in my tight jeans. Do you know some other configuration tools that do not cause this problem?
Rpmfind is cli program to query the great multi-distro rpm database in the sky, Rufus.org and its mirrors. The update automater you described that runs from /etc/cron.daily is actually "Autorpm"--and also some other perl scripts like Rhlupdate if added to a crontab. Gnorpm manages rpms installed on your system but it also includes a feature many users overlook: "web-find" which is a graphical frontend to rpmfind. This can act a little like apt in that you can enter a simple, unversioned packagename, and Gnorpm/rpmfind will go find and download the appropriate package for your distro/version--and if I'm not mistaken it will also suggest/offer to download dependencies. (I guess you can tell I do my own downloading and installing). It's not as automatic as apt-get install since the commit to install only comes after the package(s) is downloaded.
In the Windows world, that little utility you want to install insists on installing the latest Internet Destroyer, too, and twenty other things which you either already have or earnestly do not want (nagging registration reminders) on your drive. ./configure && make && make install over what happens to people in the "Windows World", the poor benighted fuckers. I'll grant that in the last case, I could do it faster by dl'ing a binary, but so what? In the Debian or FreeBSD scenario all i need is the name of what i wish installed. Can't beat that.
I'll take apt-get install thingy or even rpm -i thingy--hell I'd even take get thingy; tar xzvf thingy cd thingy
...it is good ;)
<^>_<(ô ô)>_<^>
test
"Karma can only be portioned out by the cosmos." -- Homer Simpson
Mabie I have never heard of Linux in my whole life. And so when I ever getr connected to the internet for the very first time, I see an People using another operating System, Linux. And a new Operating pops up from nowhere rising way up to the second right below MS and mabie I don't even have an Idea what the hell it is yet.
What package manager is the best right now? we have a few, Debian Package system, RPM, the good-old tar.gz.. I personally think the debian system is superior from RPM, because much more effort has been to make it work good. But still, many bugs seems left. Perhaps we need some completly new designed system, with the commen bugs in mind? theswitch
Don't mess with my autoconf. Yhis guy talks about an enormous amount of effort wasted on distributing software in all the different package systems. Here's an idea for you: don't use package systems. ./configure ; make&&make install is as easy as it gets.
Slackware owns j00
For linux software we already get to choose from half a dozen different packages, .tar.gz, rpm for redhat, rpm for suse, deb, tgz or whatever for slackware, etc etc
To make matters worse you need different packages for different architectures so now we have an x86, alpha, powerpc, sparc, strongarm version of each package mentioned above. Thats already 5x5 packages just for these formats. The number of distros is only going to increase so clearly this isn't scalable.
Inevitably some distros will get left out. This is already happening, eg Quake 3 demo lets you choose between an .rpm for RedHat and a .tar.gz for everyone else
A single package format could reduce the confusion and make life simpler for everyone. It looks like the LSB are looking at defining a standard "LSB package". Well more power to them as this is what's needed.
The SVR4 package system used on UnixWare and Solaris works pretty well, and is already familiar to major (commercial) developers. Why not port and adopt that. Trying to standardize on .deb or .rpm will just start a turf war between the major distros, which is no good for anyone.
No offense, but I have to disagree with your assessment that Windows has a huge edge in installing applications. Yes, there are more pre-packaged applications for Windows than there are for all flavors of Linux combined. Hell, there's more prepackaged Windows apps than there are for all other OSes combined.
However, the issues are ease of installation, ease of configuration and ease of uninstallation.
A few weeks ago, somebody in my department needed to read a file created in Photoshop (one of those .PDD files with all the layers). Nobody in our department had Photoshop and none of my other image editing software could read .PDDs. So I went over to the Debian machine I've been futzing with, started DSELECT and looked for GIMP. I hit the + sign for the GIMP and DSELECT automatically showed me all the packages I needed to install with it.
I told DSELECT to install and it used APT to go to a Debian archive on the web, download the packages, unpack them, configure them and clean up after itself.
Total time from initial realization I needed the GIMP to completely installed and functional GIMP: 8 minutes. Later, we decided that the file we had was too big and unweildy and got the artist to cut it down and send it to us in a format supported by some of our other graphics programs, so I uninstalled the GIMP and any associated packages. Total time for that: 2 minutes.
If I'd installed Photoshop on a Windows PC, I'd have probably had to reboot, because everything you install in Windows wants you to reboot. Same deal when you uninstall.
As for people who think that source packages are the way to go, I'll reserve judgement on that, but I don't think you'll ever get novices running Linux or any other OS if it requires them to compile their apps before they can use them. There's just too much convenience in grabbing a pre-built binary package and installing it.
"What happens when X is broken and you need to install xserver-foo to get it working?"
Debconf will fall back to one of it's other ui's automatically. Once I or someone else actually writes a good X ui, that is..
--
see shy jo
Yes this looks very interesting, I'll check it out and maybe switch over. Looks like it has a package-management-style interface (epkg) and package "format" without losing the ability to stow any old thing. Very cool!
Don't think of it as a flame---it's more like an argument that does 3d6 fire damage
Actually I really do mean /lib. I did it once, too. :) I wasn't using stow per se, but a little script I had hacked up (before knowing about stow) to do the same thing.
Even if all your stuff is dynamically linked you'll be OK unless you blow away the package directory with libc. (But by that point, you're really screwed, anyway.) For one, your shell probably has built-ins that do things like mkdir, and even if they don't, don't forget about LD_PRELOAD magic.
Just don't have root running a dynamically-linked shell, or don't log out. ;)
Don't think of it as a flame---it's more like an argument that does 3d6 fire damage
Any OS that doesn't have symbolic links can... uh, never mind. ;) Are there any unices that don't...? I'm afraid I've only worked with Digital, AIX, Solaris, BSD, and Linux... any widely-used filesystems out there that don't, or any good reason for avoiding them...?
I think supporting non-unices is rather a nonissue, since they tend to be so different that you couldn't have such a scheme generic enough to satisfy them all. Perhaps, though, you could have a system that says "this is a binary, this is a config file", etc., and the backend would install it in the right place. (Like automake, I guess.) For unices with symlinks you'd use a scheme like stow, and for other OS's you'd use something they like.
Dunno.
Don't think of it as a flame---it's more like an argument that does 3d6 fire damage
Hmm yeah, I think deb's and rpm's both can build from source too. Encap (as mentioned by another poster below) seems to have some of the above mentioned features though. Probably using one of the post-install scripts one could go about running a configuration thing too, but I'd much rather prefer a linuxconf module or something similar.
Don't think of it as a flame---it's more like an argument that does 3d6 fire damage
Actually stow offers the same advantages as before. You just stick stuff in its own directory, and stow it. If it's not in bin,lib,man etc. format, you can put it that way with little trouble. (For totally problematic packages like StarOffice which just make a big mess, I have a separate /usr/local/packages directory where things go and don't get out-linked. Easy enough to make a menu entry to launch the given application, and keeps things clean.)
Dependencies tend to be a non-issue with autoconf. If you're missing something, it'll tell you what to get and where to get it. Some sort of automation would be nice here, of course. It's certainly possible (look at Perl's CPAN shell), and would make building pretty easy.
It does handle conflicts, though, by telling you there's a conflict. I don't know how else you'd want this handled, but I'm sure any number of schemes could be devised.
Don't think of it as a flame---it's more like an argument that does 3d6 fire damage
Actually all you have to do is make sure stuff is in a properly laid-out format and stow will happily do its magic. (It'll do its magic regardless, you might just have a mess on your hands if it's not proper though. ;)
I could say that naive users shouldn't be administering systems. Maybe I'd even be right in certain contexts. But realistically, new (Linux) users aren't going to be able to compile stuff. (They aren't. When people who can ask questions like "This says, 'error: unable to find freetype, please install it', what does it mean?", you know the total newbies are going to be lost.) Encap as mentioned below (or above I guess depending on your comment ordering ;) might be able to solve this, and allow regular package management without relying on or requiring proprietary formats.
Ports have always sounded pretty cool. But from what I've seen, it's not the complete solution we're talking about (where you put the files, and how you remember what belongs to what, etc.), but then, I haven't really used them, so I'm probably wrong.
(For clarification, I'm a RedHat user at the moment. I've used everything, from building my own system from the ground up, to Slackware, Debian, and even other lesser-used distributions such as Yggdrasil... ;) Package formats such as deb and rpm are proprietary, not in storage format (rpm's use cpio or something), but by composition and requirement. They are composed in a format that is exclusive to their own system of doing things (having specific files in the archive with meta-data about the package). They require their databases and their tools for using. They also require someone specifically construct them. (Waiting for that latest release of XFree86 or some other shiny new thing? Both Debian and RH have at one time or another lagged behind.)
This isn't necessarily bad, it's just rather limiting, and at times frustrating (try extracting a deb or rpm without the proper tools... rpm2cpio, whatever deb has...), but it works. The thing here is that something more generic can be used in the same way.
You're right though. Requiring everyone know how to build from source is going to restrict Linux. But perhaps we can come up with a solution using stow-like methods and a more newbie-friendly frontend (encap maybe?).
Don't think of it as a flame---it's more like an argument that does 3d6 fire damage
And this will install all the dependencies, as well as downloading everything from the Internet. Just come back later.
I totally agree. The whole point is not about packages; we have plenty of types of these already. It's about *meta* packages, and creating these from source distributions so that they can be easily integrated into your operating system.
eg: If I compile a program on my Solaris box, I want a pkg for it to be created in pkgadd format, so that I can distribute it to my other Solaris boxes. Likewise, on FreeBSD, I want it in pkg_create format. And on Linux, it needs to be RPM.
What is needed is a package creator that understands different Operating Systems styles of packages. Dammit, if I compile under Windows, it should be able to create a installshield package for me!
-Dom
Please explain how dependencies could be added to stow without much difficulty? Stow has no procedure for handling multiple instances of the same file in different packages, let alone ensuring that a given package gets the versions of the libraries that it needs (different packages require different versions of libpng, for example).
p.s. stow requires perl, which requires libc, which would get killed by a rm -rf /lib. /usr/local heirarhcy for example, where the files are installed? The former makes things such as GNUstep get rather nasty, since things aren't relative to GNUSTEP_SYSTEM_ROOT, and the latter makes organisiation difficult, since the file->package relations break down.
Also, when make install'ing a program, should the program look directly inside the stow tree for its files, or inside the
In short, more flexible 'framework/build-tree' organisation methods are required for things such as KDE, GNOME or GNUstep, such that each gets its own sub-heirarchy, and files are installed based on policies local to each.
John
John_Chalisque
forget files and symlinks -- the configuration system doesn't need the complexity of the entire filesyste, while at the same time it does require extra facilities to be managed efficiently (e.g. how are users' changes stored, what about group configurations (so you have a system default, a group inherits and modifies it, and then users from a particular workgroup may inherit from that, picking up any alterations AS THEY ARE MADE).
The long haul solution is to virtualise the entire user-visible heirachiy, and present THAT in the /usr filesystem (which would then look different dependant upon which user was logged in -- i.e. user filesystem -- with system stuff in /sys for example)
The point that must be reiterated over and over again until understood is that the
In the long run, EVERYTHING must be questioned, from languages to build trees to user-visible filesystem (and what such terms mean).Many people quote the 'Unix approach' as begin 'do it once, do it right'. That is not plausible unless you are prepared to throw away everything that isn't right in persuit of 'doing it right'. Eventually, incremential changes must be binned in favour of a complete redesign, followed by a complete rewrite. (people should take note that a total rewrite alone doesn't work -- you just reinvent what you had before, with a few changes)
John
John_Chalisque
I couldn't agree more! I have been using a similar setup for many years. It was a trick I learned from the sysadmins at Intel who had to manage multiple version of packages on multiple platforms for the whole site (thousands of engineers). Stow scales.
Personally, I think that encouraging binary packages is a Bad Idea for the Free Software community.
FWIW, here's the simple script that I have used for years:
#!/bin/bash /usr/local/units/$1 /usr/local/{} \; -exec chmod 755 /usr/local/{} \; /usr/local/units/$1 /usr/local/{} \; -exec ln -s /usr/local/units/$1/{} /usr/local/{} \; /usr/local/{} \; -exec ln -s /usr/local/units/$1/{} /usr/local/{} \;
Scary, eh? I have run it on NetBSD, FreeBSD, OpenBSD, and Linux. I'm sure STOW is better and am fetching it now.cd
find . -type d -exec mkdir
cd
find . -type f -exec rm -f
find . -type l -exec rm -f
Mark
drool.. I like your thinking, Aaron. My phd thesis is about a limited form of meta-reasoning for compilers. Whenever I see someone else who groks the power of "meta", I am happy. thanks!
Obviously, when the prospect of supporting a new platform is raised, I groan inwardly. No actually, I groan loudly too. As for supporting the many different variations of platforms (e.g. Alpha, SPARC, PowerPC, Debian/Caldera, etc.) - FORGET IT! It would take a month just to get a new release out of the door. (Obviously, there are also issues of available hardware, development, support staff, etc.)
I see a lot of commercial Unix software that is supplied in tar or cpio format with a customised install script, so obviously others have opted to circumvent the above hassle entirely. However, this way you lose the benefits of the system's own software management, versioning, etc.
I like RPM myself as a user, but it doesn't solve my problems as a packager because it's not standard. And heck, why should anyone bother fixing or improving its deficiencies when they can just write their own packager?! Yeah, make that wheel rounder! Sorry, I'm starting to sound bitter...
In an ideal world, software would come in source format and there would be an easy config/compile/install tool for all of it. In practice, it ain't never gonna happen. Even if we did bravely decide to release open source our products, at present, I wouldn't trust all our users to have a working compiler, a correct set of libraries or necessarily, a clue.
A good package manager supplies:
A really good package manager would also work on any platform. I don't think one can count on vendors like Sun to support a new format unless it becomes either a formal, popular or defacto standard (hey, they have eventually bundled gzip and patch!). Therefore, executable installers (consisting of the software plus a standard wrapper for the platform in question) would seem to be required. In turn, this infers the need for an easy way for developers to build such packages on any single platform, requiring only the pre-built platform-specific parts (binaries and libraries) from elsewhere.
Ghod, I'd love that.
(Alternatively, tools that convert, create or unpack multiple foreign package formats would be nice. I'll have a look at PkgMaker.)
Ade_
/
Big Bubbles (no troubles) - what sucks, who sucks and you suck
You actually can gen a system entirely from source using Debian. It's pretty cool -- and, of course, you get to choose from all of the nice Debian 'recommended' dependancies rather than just being restricted to the 'must-haves' which the other choices give you.
;-), but I'm just curious.
Not that BSD's system isn't cool. It's very much so.
Say, in BSD can you upgrade an entire system across versions while regenning it from source? That's not something I've ever been tempted to do in Debian (I'm happy with binaries when I'm doing full system upgrades), so I can't say that it matters
-Billy
While Windows may make package management appear easy, that is an illusion just like the rest of Windows.
The amazingly poor package management systems available to Windows users are what inevitably lead to what is so common it has a name: DLL Hell.
It is actually easier in the long run to install a program from source than to install a bunch of random executables and libraries and hope they aren't incompatible with what any number of users have previously installed.
After all, which is really easier:
- navigate to download directory
- run setup.exe
- crash the next day
- crash the next day
- uninstall the application
- crash same day
- crash again later that day
- reinstall OS
orWhy do I have an opinion on this? Because for the last five years my "day job" has been release engineer for a package with nearly 20,000 files and over 3 million lines of code. People really shouldn't even use "package management" and "Windows" in the same sentence!
-- OpenSourcerers
I've created a program called autospec that can create spec files automatically from the contents of a .tar.gz archive. If the archive contains a Linux Software Map (.lsm) file, then there's a good chance that the resulting spec file will require no tweaking, but in most cases you'll probably need to edit the result somewhat. It does eliminate most of the grunt work involved in creating a new spec file from scratch, however.
The man page is available at . See for more details or to download. There are other RPM developer resources listed at .
This sounds like it will bring one a long way towards .tar.gz -> .rpm.
The way I see it there are two types of users. Those that just want the software to install and those that care about compiling and optimizing their installation. These two groups are roughly equivalent to windows and linux users respectively.
/usr/local/sbin)
/usr/local/program which will also remove the hard links in the binary diectories.
/quite or /common installs but this is not the default). Assume that the user is not a technician. If they are a technician they can figure out how to configure things for themselves.
Here are some suggestions
The configuration files should somehow conform to a standard XML conf file format which can be read and edited by various all purpose configuration programs. (web interfaces/console programs/x programs)
The package should default to installation in
/usr/local/program
/usr/local/program/etc (for configurations)
/usr/local/program/bin (binaries)
etc.
Hard links should be created pointing from '/usr/local/program/bin/program' to '/usr/local/bin/program' or the proper binary directories (i.e.
Side note: This is one ease of use I think shines over Windows, most programs are by default stored in the path under linux/BSD/unix. Instead of having to search through menus and directories for a certain program users merely need to type the program name.
Also create a program-uninstall script which goes in the binary directory. All this script must do is delete
The package should have two installation methods.
Note that simplicity should be the default! I believe some windows programs fail in this area, nearly always asking users which directory to install in, whether to create icons, etc. (Sure there are
1) There should be an 'install' script in every distribution which copies binaries and libraries files to the '/usr/local/program' directories.
Non-technical users will then only need to execute install, program, or program-uninstall to get their work done.
2) For the more educated users who are not afraid to compile then the normal configure,make, make install, Makefiles, etc will provide all the confiuration they desire.
There are many ways these ideas can be improved upon but I think we must remember the default should be simplicity, with this we can actually beat windows software. On the other side configuration should be provided by an XML file for each program. This would allow for multiple editing methods. Being able to edit files by hand is a valuable option. For instance with a scheme like
<program-option>
<description>This option sets default preferences file<\description>
<example>/etc/globalpref</example>
<value>$HOME/.pref<\value>
<\program-option>
an administrator could easily configure a program with pico yet a person could write a X app to do the same.
If people are looking for something like STOW, they should take a look at opt_depot. opt_depot is rather more developed than Stow, and includes support for managing package archives in an NFS server environment.
The only downside to opt_depot is that I haven't filed the paperwork to release it under the GPL.. I've been too busy with Ganymede over the last few years to mess with it.
Note that opt_depot itself hasn't been very actively maintained for the last few years, but some folks at the National Library of Medicine are supposedly preparing a new release based on it.
- jon
Ganymede, a GPL'ed metadirectory for UNIX
Keep in mind that their are a lot of systems for handling installed software via symlinks, and most of them have unique strengths in particular circumstances. I have a list of many of them at my opt_depot page, including CMU Depot, Stow, Epkg, and several others.
With the exception of Epkg and LUDE, these systems tend to come into play only when it comes time to install and manage installed software on your system and/or network, so it isn't so crucial that everyone use the same software.
Epkg does seem to be one of the best out there now, at least going by the feature list on the Epkg web site. I know that opt_depot is uniquely easy to manage on an NFS network with central package archives, and we and others have been running on it for over 5 years now. I doubt that you're going to get everyone to use Epkg, but it's good to see the work that the UIUC folks are doing on it.
It might not kill them to acknowledge the many alternatives to their software for this very commonly implemented idea, however.
- jon
Ganymede, a GPL'ed metadirectory for UNIX
Funny - this is pretty close to what I do now to maintain my system. The difference is that I've decided that a really long-ass $PATH and a really long /etc/ld.so.conf is not such a bad thing.
/usr/Applications directory, you'll find a directory named Netscape-4.7 and one named Netscape-4.5, and a symbolic link to Netscape-4.7 named (amazingly enough) Netscape.
So, if you wander into my
/usr/Applications/Netscape is part of my $PATH; the two directories with version numbers in their name are not.
It makes it really ludicrously easy to back out of installing a new piece of software and go back to the earlier version - delete directory, delete symlink, make new symlink.
Ack. Don't use stow. Use epkg and the encap package format, if that's what you want to do.
:: "I am non-refutable." --Enik the Altrusian ::
A zip-file is just an equivalent of .tar.gz on Linux so I don't understand the comparison.
And you know, InstallShield is just a nice GUI above a inferior installing system.
In fact, Windows is moving towards something similar to deb and rpm packages in W2K where they have a new system Windows Installer. I can't tell much about it yet, but I'm going learn how it works and hopefully our company can dump the inferior InstallShield scripts.
Actually, I think that deb works pretty good already. It's just that the user friendliness of installing deb packages could improve. I like apt-get, but a regular Windows user would be horrified with the CLI.
At least with encap, encap binary packages are quite available. As for dependencies, it is true those are not handledas much. However, in general many package management systems do a bad job with this. I end up using the force options to rpm a lot when I use it.
That works OK as long as the program is a standalone application that does not export anything useful to the outside world.
/home/joepublic, /home/httpd, in an SQL database, and so on. I don't see the problem here.
Export what? The shared libs are in "frameworks" - whole bundled trees of libs, headers, and API docs. Programs communicate via fifos, pipes, sockets, clipboards, or object broker systems such as CORBA or GNUstep Distributed Objects - just like they normally do. Shared data is in known locations:
Bundles co-operate with the old unix way of doing things.
/bin, /lib, /sbin and so on. Any app you might expect to start by double clicking an icon in a GUI lives in a bundle. These can be made environment-neutral by containing multiple binaries for different chiptypes, and multiple resolutions of icons, each in pre-specified places.
/lib and /usr/lib. Any cluster of libs which (a)you only ever use as a cluster (b)you normally use in developing GUI apps or (c) have a cluster identity of their own live in a Framework under the frameworks path (eg: /Libraries, /Network/Libraries, /home/jimbob/Libraries). Examples of this would be GTK, Gnome, KDE, the NeXT Webobjects package, and so on.
Basically, CLI and system stuff lives in
The core OS libraries like libc and so on live in
It's possible but unlikely that you'll want a package manager for the relatively small fraction of non-application binaries, but unless you're upgrading the OS core (as opposed to installing new apps on it) then you won't need to mess with them.
Hrm, I can't remember the last time I had to upgrade a kernel before I could install a package...
:)
Dependencies aren't there, because an application will happily install whatever vesion of a system file it needs - even if that breaks other apps that need a newer version. Maybe there are some dependencies after all, eh...? Just working in the other direction
----
"I'll do a make and make install and *boom* suddenly it overwrites the rpm's files."
You can hardly expect the package manager to keep track of things when you don't use it. If you make an end run around rpm and modify files directly how is it meant to know? That said "rpm --justdb -e binutils" will let the rpm database know that the bin utils package is no longer installed and leave your own files alone. If you later reinstall the RPM your config files will be backedup.
"also, rpm -qpl should put a header"
rpm --queryformat 'Package: %{NAME}-%{VERSION}\n' -qlp *
... with eskimo chains i tatto my brain all the way...
logan
Debian rocks.
logan
Not to be picky, but for "packaging" and an editorial on required components, it's ironic you forgot the "dept" tag for this post. ;)
There's no need to reinvent the wheel. The latest version of RPM is capable of building binary RPMs directly from pristine tarballs (if the tarballs are formatted a certain way) using one invocation with the -ta flag. It would be rather trivial to extend that to automatically install it, after the binary RPM has been built. Let's say...
rpm -taci tarball.tar.gz
("-taci" is the acronym for tarball compile and install)
or,
rpm -tacir tarball.tar.gz
... which would be the same thing, except instead of installing the binary RPM directly, it would execute su root -c "rpm -i tarball.%{_arch}.rpm". This would be usefull when doing non-root rpm build-roots (as everyone should be doing already).
--
>ldd `which ln` /lib...> /lib without these
/usr/local/lib. But I could of course
>ldd `which mkdir`
<snip linraries in
>Anyway, how am I to recreate
>tools?
Because you have a statically linked binary that
performs all these operations via symlinks, in
/sbin.
If you don't, why not? Be prepared for doing
stupid things at 4am when you really were
too tired to be installing a new kernel.
I suspect that the original poster
meant
be wrong as usual.
I'm surprised nobody's mentioned the Mac Gestalt Manager in this thread... from what I remember (years out of date by now, I'm sure) it offered an extensible way to query the OS for installed capabilities. While there were several standard gestalt selectors to query for information common to every system, third-party software (primarily system extensions, IIRC) could install additional selectors to indicate their presence, configuration information, etc.
"Great men are not always wise: neither do the aged understand judgement." Job 32:9
This package manager has a number of good features, and works well with both command line, and gui interfaces. Here are a couple of things that this tool has been able to do for years.
-interactive conflict resolution. The user gets to see what will get broken or overwritten, and has a chance to choose from different options.
-Removal of software even in the middle of installing it. I once ran out of disk on a few of these machines, switched modes, selected other software not needed, marked it for removal and continued without a hitch.
-It follows links, and nfs mounts without any hassle on the part of the user.
-Interactive display (gui mode) of all operations, disk space requirements, and overhead for pending operations.
If you have a chance to look at this tool, it is worth the look. With a few standards for packages, and dependancy listings, it would be a very good thing. Something the MS crowd is just now beginning to realize that they need. Every windows user I have shown this to asks if they can get it for their machine. I have used many of the various package managers for Unix and Linux, and this one is the easiest, and most robust out there. SGI are you reading? Maybe this should get onto the project list...
Blogging because I can...
I like the ideas behind the debian one. It is as good of a choice of the IRIX one, maybe more of a logical choice as it does not have as many issues regarding licensing. I *really* like the IRIX window manager and assorted GUI tools. They paved the way for ease of use under UNIX, and don't want the work they have done to fade into a niche unless it has to.. :-) Basically the SGI environment allows you to command line, and GUI or both depending upon your mood or need. Pretty painless either way for most common tasks.
:-)
In either case, the key needs to be flawless execution, and very straightforward interfaces, at least on the GUI side.
You should pitch what you like, I'm gonna
Blogging because I can...
Is the fact that a lot of code used in linux can also be used in other unices. Not so in Windows. Windows programs usually install pre-built binaries, *nix (free) programs don't.
:)
There are a ton of package managers out there for binaries - and it's a fairly easy thing to manage. But before you go on and on and on about how much linux package managers suck, realize that you're talking about 2 different paradigms.
Also remember that you'll no longer give a damn about packages once you've actually learned to use your *nix of choice.
--
blue
i browse at -1 because they're funnier than you are.
however, don't source rpms do most of these things? the compilation will use ./configure, make, make install so you have the cross-platform advantages of autoconf and the extra advantages of having a package compiled to fit your system.
a bad point is that you have to interpret compilation failures
btw, packages are coming to windows in the near future via the new installer service thingy that comes by default with win2k.
stay frosty and alert
I have. DX7. And surprisingly it wasn't for a game. And then there's the thing required by Active State's Perl when installing on Win 95 systems....
cheers,
sklein
apt-cache search package
apt-get install actual_package_name
What's the problem? Yes, you have to learn that. You have to learn to click on the windows thingy, too (believe me, you do. I've had to explain it to people).
It's very simple, easy, clean, and fast. I've had one problem so far, and that was another sysadmin messing with things on me. I've never had a problem on my own system.
Oh, and for extra benefit, debian installs tend not to kill your other programs, which windows installs are famous for. From what I understand they're getting better, but getting programs to work together is just as important as getting any individual one to work. If one program kills the rest, guess which program goes?
They laughed at Einstein. They laughed at the Wright Brothers. But they also laughed at Bozo the Clown. -- C. Sagan
Well, I've been doing some packaging (rpms) lately and noticed the following issues:
The quality of the packages is often bad. The packages included in distributions are mostly good, but the contrib packages need work. For example:
- During the build packages often install directly into the "production" filesystem, with the chance that things get left behind (filesystem polution).
- During the build packages try things like "install -o root " which can only be done by root. Users aren't able to build the package.
There is no "central" contrib repository. I beleive this is needed. So much work is being duplicated by the different distributions in this area. As far as I can judge, distro's aren't making money on contribs, so why can't a joint effort into a contrib repository be started? (Nice web interface, latest package (for different systems / distro's, latest available TGZ, status of build on multiple platforms {alpha, sparc, x86} etc. etc.). Something like rpmfind.net?
A compatible packager, or a standard in packaging (not only covering Linux, but also the other unices) would be nice, but let's face it, can it be done?
If you're looking for some guidelines on building rpms, take a look at: http://www.linux-mandrake.com/howtos/mdk-rpm/
Stefan
The FreeBSD port system is without a doubt the most elegant of all the Unix packaging systems out there. The Linux world really should "embrace and extend" what they can from the port system.
I'm skeptical about creating a centralized control. What do you do if it gets corrupted? Your whole system is shot. What if you are on a multiprocessor system, and one process locks the control, and then freezes? Distributed information seems more robust.
OTOH, there's nothing that says that there couldn't be a lookup table for fast access. I'd just like the master information to be distributed.
(Tyro warning! I don't yet understand the Linux file system, but I'm making proposals anyway!)
What I envision would be a file in each directory that is local to the routines installed in it, and maintains the information about the applications that reside in it. This has the defect that mv, cp, et. al. would need to be aware of the application's information.
An alternative is to swipe the idea that the Macintosh has about each application having a resource file (well... actually a packed directory) attached to it. This works quite well, but does have a lot of system support. This involves redefining the file structure so that each file has a data fork and a resource fork (unless the Macintosh originally swiped that idea from Unix).
Both of these last two ideas allow the "registry" to be reconstructed in case of any problems, and prevent the whole thing being locked-up by one process. (The Mac rip-off allows applications to be moved around ad-lib, though the location of shared libraries would still need to be fixed.)
I think we've pushed this "anyone can grow up to be president" thing too far.
It all depends on the distro.
.tar.gz files and build, you are most likely a programmer, and can figure things out.
If you are willing to stick to the content of the official RedHat CD (to use this as an example), you get all the software in one format -- RPM -- that works with the _built in_ "installer / uninstaller".
This is the more typical experience for an end-user (e.g. not a programmer).
If, OTOH, you are going to download
I read the article too, a few days ago. Very well written, and about time someone got on a soapbox about it.
SRPM's are nice, but..One thing has to happen. We either all need to decide on a distrib, or we all need to decide on a packaging standard. Guess which is going to be the easier of the two to do? Packaging.
I'm all for a universal packaging standard. Call 'em
Bowie J. Poag
Project Manager, PROPAGANDA For Linux (http://propaganda.themes.org)
Bowie J. Poag
Yes, you will find exceptions. YMMV.
-----
--
perl -e'$_=shift;die eval' '"$^X $0\047\$_=shift;die eval\047 \047$_\047"' at -e line 1.
make uninstall usually works.
And issueing a 'locate app-name' usually spits out all other leftovers.
This if from THE department, with a capital THE.
It is the author's belief that the time is ripe to start working on a universal source package system.
I can see why it took a PhD to write this article.
DrLunch.com The site that tells you what's for lunch!
Yes, for example, sendmail "provides" mail-transport-agent. Other examples include java-virtual-machine, mail-reader, httpd etc. I'm unsure how this works in practice though, eg. if i don't have a mail-transport-agent installed, does it pick one??
You can reinstall packages with "apt-get --reinstall install foopkg".
Which version of apt do you have? When I use the --reinstall option I get:
E: Command line option --reinstall is not understood.
Or where you trying to make a joke?
Quack
True, uninstalling software under Windows is certainly not an "exact" science :). However, most users don't even think that far ahead. They want program X to install and run and be done with it. When they eventually try to uninstall it, I think it's a safe bet that most users don't even think about "Gee, the program directory is gone, most of the icons are too, but did it clean up the registry? Did it accidently remove DLLs that other programs are dependant on?"
They just want it "to go". It's tough job to meet their expectations without compromising the "grace" (for lack of a better word) of Linux (yeah, yeah, any other flavor too).
Question is: Do we want to? I know everyone talks about "Yeah, Linux on every desktop" and all, but really, what's so wrong with it having a "niche" market with the more technically savvy users?
Ooooh, Enchanter flashbacks... Heh, it even fits. Writes a spell scroll into your spellbook for later use.
Cool.
(I'd suggest adding frotz for a command, but it's already a Z-machine interpreter...)
Let's see: gnusto (installation/package tool), rezrov ("unlock/open" == chmod?), malyon ("animate object" == filemanager/program launcher?), filfre ("useless fireworks" == eyecandy something). Oh, this has possibilities... ;-)
This
I believe there are already bugs filed against all of these packages. You can urge the maintainer of the package to fix it by writing him at packagename@packages.debian.org.
> apt-get install
>
> Debian rocks.
I agree, but remember you need to "su" first.
I agree that the Zip-InstallShield method in Windows makes installing software easy. But the pain of ever uninstalling software is tremendous. Never once have I seen a package uninstall itself without leaving dangling references in the Start menu, leaving partially empty folders, breaking another package's installation, or simply complaining "Unable to uninstall" and leaving me to delete the files manually (and hoping I don't break another package in the process). My favorite features of RPM are its treatment of uninstallation, upgrading, and tracking down a package's configuration files.
I think RPM is a good thing from an end-users point of view. It allows easy installations and upgrades to packages without much work on their part. It's a good model for the desktop.
It fails in other ways though:
Problem 1 stems from the
Problem 2 is a big issue for people managing huge sets of machines. How do you remember which machines have which packages installed on them? Sure "for i in box1, box2..." type solutions can do this but it's a pain in the neck. What I want is a DB that can handle remote queries (actually, I have the beginnings of this worked out via SNMP queries but...) and can list for me the machines with differences from the rest, packages that are on every system, systems that are missing package X, etc. And, of course, you should be able to say "with respect to architecture Y" for any of these queries.
Problem 3: Not everything comes in RPM or any other distribution package format. You need something that allows you to automatically append to the DB the files that you're building and installing.
Actually, I wrote a small utility a few years ago to handle problems 2 and 3. Basically, you keep an INSTALL variable set in your environment so configure uses that by default and it points to a hacked version of an bsd install script. Then, you run configure, make and make install just like you normally would and the INSTALL script automatically updates a database saying you installed all these files attached to a package with a version number. Hmm... I think I even have a sample output somewhere:
% sdb -h
usage:
sdb -add PKG VERSION FILE...
sdb -chart [PKG [ARCH]]
sdb -list [PKG [ARCH]]
sdb -report
sdb -compact [-verbose] [-check]
sdb [-cset|-sset]
sdb -setup [-arch] PKG VERSION
sdb -remove [PKG] [VERSION] [FILE]
% sdb -chart
package Linux_2 SunOS_5 HP_UX_B_10
x11.xscreensaver 3.10
gnu.cvs 1.10
x11.libjpeg 6b
contrib.pgp 50i 50i
ucd-snmp 3.5.1
gnu.patch 2.5 2.5
gnu.fileutils 3.16 3.16, 4.0
gnu.groff 1.11
contrib.ssh 1.2.26 1.2.26
flex 2.5.4
I set it up for a common disk path (eg,
The nice thing about it is that it is easy to use... "sdb -setup XXX 0.0.9;
However, it needs to be re-done to handle the multiple hosts without a common file system though.
(hmm... the chart should be properly spaced... HTML is slamming it without pre tags, which isn't allowd by slashdot)
The next site to slashdot will be ready soon, but subscribers can beat the rush and start slashdotting it early!
Also, a GUI config tool for packages would be very nice. Newbies can get scared away by Debian's text-mode config scripts. But progress is already being made in this area. The frozen potato (Debian 2.2) already includes a front-end for package configuration.
Not to nick pick or anything, but debconf (the front-end) is still text, but it is curses based so it looks somewhat Goowey. I don't think that it would be that good to have a gui installer anyway. What happens when X is broken and you need to install xserver-foo to get it working? I have no problem, per se, with a gui deb installer, as long as the cli one stays as good as the gui.
Also, I love being able to be sshed in, and have the ability to install stuff that I might need. Can't do that with a gui installer.
I wasn't lost... I was only momentaraly confused of my spacial orientation relative to my prime destination.
Funnily enough, I've been thinking along the same lines while writing a general package management specification. A small amount of info in source packages is a hell of a lot simpler than anything else. However, there are many big packages out there that don't even use autoconf, so getting them to add packing info is less than likely.
Well, ok, but if you manually keep track of dependencies it works. Not as good as automatic dependency tracking, but better than having to fish out 00s of individual files.
perl -e 'fork||print for split//,"hahahaha"'
I think this does what you want. (It temporarily deconfigures packages which depend upon things replaced by foo, then reconfigures them)
perl -e 'fork||print for split//,"hahahaha"'
> Would you prefer that the package manager erased
> [user config directories for removed apps] for
> you? I think not.
No, removing a pacakge shouldn't remove any user's files, but it would make sense for each user to get a pop up dialog when they log in telling them that they have config files for uninstalled packages, and offering to remove them. It should explain what's happened and what the ramifications of removing the config files are. In addition to "yes, blow them away" and "no, keep them around", there should also be an "ask me again next time" option.
I wouldn't think such a facility would be difficult to add to, say, debian's package facility. Of course, there's not much chance of removing config files which users have chosen their own names and locations for.
What debian doesn't do is keep track of which packages I selected directly, and which were only selected because they are required by other installed packages. This distinction is important, because a package I didn't select directly can be removed once the last package that depends on it is removed. I have no idea how many packages I have installed that I don't need or want, and there's no easy way to find out. Every so often I do a spring cleaning, but this is time consuming and would be intimidating for newbies. Having this handled automatically would make uninstallation simpler and more effective.
My other complaint about dpkg is really about its front ends. I'd like one that would do the following for me:
I think these features would make debian's package facility quite efficient and friendly, even for newbies and people using the unstable release.
Your not wrong, but the bottom line is, it would/should be trivial to implement a package managment system based off the FreeBSD Ports system to encompass ALL linux distros.
:>
FreeBSD's ports system uses a basic system include file. If all the distros can agree to use the same system include for the locations of the relevent parts of thier distro, problem is solved.
Should be a no-brainer, if Linux companies will 'lower' themselves to taking something from FreeBSD.
One way to solve this is to have a 'system descriptor' include file in your 'linux ports' system.
This would make the port skeleton look the same for all distros, but allow the system to define exactly where and how to put the results of the compile.
Throw in the 'registry' style tracking system you get with *BSD ports, and you get a good software maganment tool (not great, but good)
Here are the scripts that I use to do just what was suggested. This doesn't work with dynamically linked libraries (whose directories still need to be added to
#!/bin/bash
# Paul Schulz : August 1999
# usage: local_link (in software home directory
# For each file in selected subdirectories
# a link will be created from the corresponding system directories..
# eg.
# unless a link already exists by that neme.
localpath='/usr/local';
IFS=:
dirs="bin:lib:include:doc:info:sbin"
dirs="$dirs:man/man1:man/man2:man/man3:man/man4
dirs="$dirs:man/man5:man/man6:man/man7:man/man8
dirs="$dirs:man/man1m:man/mann"
function link_dir
{
pushd $1 >
echo "In Directory: $1"
for prog in *;
do
echo -n " Creating: $localpath/$1/$prog -> $prog"
if [ -L $localpath/$1/$prog ];
then
echo " (a link exists)";
echo `ls -al $localpath/$1/$prog`
elif [ -e $localpath/$1/$prog ]; then echo " (a file exists)";
else
ln -s `pwd`/$prog $localpath/$1/$prog;
echo " - linked"
fi
done
popd >
}
for dir in $dirs
do
if [ -d $dir ]; then link_dir $dir; fi
done
----- and -----
#!/bin/bash
# Paul Schulz : August 1999
# usage: local_clean
# removed any links in '/usr/local' that point to
# nonexistant files.
localpath='/usr/local';
IFS=:
dirs="bin:doc:info:man/man1:man/man2:man/man3:m
dirs="$dirs:man/man5:man/man6:man/man7:man/man8
function clean_dir
{
pushd $1 >
echo "In Directory: $1"
for prog in *;
do
if [ -L $prog ] && [ ! -e $prog ];
then
# link=`ls -al $prog`
echo " Removing stale link: $prog"
rm $prog
fi
done
popd >
}
for dir in $dirs
do
if [ -d $localpath/$dir ]; then clean_dir $localpath/$dir; fi
done
I think there are a few problems with this approach. Firstly, there should be some way to work with pre-compiled packages. Here, I don't think stow offers any advantages to simple .tar.gz-packages. Also, the fact that stow keeps no database of files can be rather inefficient. Have you ever removed a stowed package from a large directory tree?
But most importantly, stow doesn't deal with the classical packaging system problems of dependencies and conflicts at all, making it rather unsuitable for the job. I don't see how dependencies could be added easily without changing stow completely. It knows nothing about packages, all it cares about are directory trees. Adapting stow to deal with dependencies would be at least as hard as creating a new packaging system from scratch.
Dependy-what? ;-)
No, the VBRUN/COMCTL/CTL3D stuff is probably still there, but there are only 3-6 of these for ALL Windows software out there. Any Win9x system that's been running for more than a year tends to have these loaded on them somewhere.
-- "Vote Democrat. Because the current crop of conservatives are just bugnut crazy."
It's true it would be a 20meg package with all the DLLs it needs -- but what is 20megs of disk space these days?
;-)
And often it doesn't put the DLLs in the system directory at all but leaves them in the packages current directory.
The DLL/Library conflict issue is fundementally different from the installing issue; we shouldn't have to solve both of them at once.
Personally, I like the package mentally in the Linux world. It just is conceptually *hard* to explain to somebody coming from the Windows world in the connect-download the one zipfile I need -disconnect world of networking.
-- "Vote Democrat. Because the current crop of conservatives are just bugnut crazy."
This is an issue; however, I haven't scrummed my Windows system in about 2 years of downloading random shareware/freeware apps, and I never have to download any dependencies.
Nearly every time I want to download something new under Linux you have to deal with the "version number" dependency issue -- i.e., it works with a specific release number out to the third version number only.
'Tis true, I haven't had to upgrade a kernel for an install in a long time, but it did happen. Fun tho!
-- "Vote Democrat. Because the current crop of conservatives are just bugnut crazy."
Now you have to admit the uninstalling is less of a problem than it used to be.
And the absence of *dependencies* is huge. You can commit to downloading a 1meg file over a modem and not worry about then needing an additional kernel upgrade
-- "Vote Democrat. Because the current crop of conservatives are just bugnut crazy."
YES debian does all those things, but all those things can commit you to a lot of time online when all you wanted was that 300k email package and find out you need 20megs of "dependencies" + compiling them all to get it too work.
This happens very rarely in the Windows world.
Believe me, I *love* the flexibilty and power dselect, rpm, gnorpm, kpackeg and such give me now that I have a cable modem connection. I hated it intensely when i had a 56k (sometimes) dialup connection.
-- "Vote Democrat. Because the current crop of conservatives are just bugnut crazy."
Doh. I would have moderated your comment up (I got five points today, yay!) but I used them all up before I got to it. If someone else has points, up it, hehe. :D
Of course, this frontend I'm suggesting is NOT for the typical /. user.
Although, I'm willing to just wait and see what appears for package management. Personally, I'm pretty happy with compiling from source. I'm just brainstorming on what an average user might need.
"You ever have that feeling where you're not sure if you're dreaming or awake?"
"You spoony bard!" -Tellah
I wouldn't consider myself a troll. Just as I wouldn't consider most people around here who heavily advocate linux trolls (unless they bashed mirosoft mcneally/sun exec style).
I try to keep things "on topic" when discussing microsoft. And tend to only go off on Microsoft tangents in response to a post I see as wrong, or unfair.
I won't bring up Microsoft out of the blue for example - on an article about beanies.
i have to completely agree with you on this.
if programs had a central/consistant place to share an communicate configs the problem would be solved.
i think the the *REAL* problem is that linux is a UNIX clone and by definition thats all it will ever be
if the community keeps its prejudices towards other innovators, corporate and/or "open". making such a radical change would destroy what linux is,
an uptodate Unix clone and turn it into a better than it was operating system, with ALL its shit to gether.
never float, linux/open source is better left as is, let someone else come up with the next best thing thing.
sorry, just had to get that off my chest, maybe its just tuesday and all these freaking trolls and life is just getting on my nerves.
BTW 3/4 of my life is on a linux box somewhere. -jkg
In FreeBSD all package/port supplied config files are stored in /usr/local/etc/*, and all auto-load scripts for a package/port are stored in /usr/local/etc/rc.d/*.
It is up to the user to update their config files when they update the port, which is the same way it works for updating the entire system from source (cd /usr/src && make buildworld && make installworld)
For updating world there is a handy utility called mergemaster that performs diffs between the install /etc and the /etc in the source tree, which makes the update very quick and easy.
I suppose the reasoning behind this was that if you are going to be upgrading your software, you should be smart enough to avoid blowing away your configuration files, and will be smart enough to adjust them appropriately. It'll probably be improved round about when the new package system is introduced (sometime in the future.)
marotti.com
If you download a debian package, it will also download and install any dependant packages, as it should (imho), but there is no way for the system to know that the dependant package was installed only as a dependancy, not as the desired package. The result is, on package removal, all of the dependant packages are left floating around on the system. Unfortunately, most newbie users are going to have an extremely tough time determining which packages are critical system packages, and which packages are just dependancies for a program they uninstalled 6 months ago.
RPMs and tarballs do not specifically have the same damage as debian packages in this respect, since they force intervention in installing the dependant packages. At least the user knows what is being installed since they are forced to do it, and they might possibly remember down the road.
Ideally, package managers should have some sort of usage/reference counting on packages, so they can delete any non-system dependant packages as users remove packages above them. If nothing else, at least system administrators would be able to tell what packages aren't needed anymore.
Yeah, somebody always stops and asks for a creditcard authorization before you can download all the rest of the stuff you don't have, but need. Unless of course, M$ is in the process of driving the maker of some similar product out of business, then they're all smiles and "free" software.
The current Slashdot moderation system is made by gay communists!
There's no C in any of that.
I have seen a few programs (ssh comes to mind) that have a 'make uninstall' option if you download the tarball. Some uninstallers are, of course, better than others. Perhaps a general program that would analyze a Makefile with an 'install' "phony target" and either (a) add a 'uninstall' target to the Makefile, or (b) allow the user to uninstall the program through a separate utility. This progam would have to allow a user to uninstall personal configurations (rc files, directories, etc.) for a specific user or all users, or even all users except those who have specially requested to keep their configuration. It could even be implemented as a wrapper around make and monitor the installation (or at least make backups of any files that make would replace), sort of like CleanSweep SmartSweep for Windows. I am thinking kernel module to monitor a specific process. This is starting to sound a little overkill, but how else do you think it was done in Windows?
Make me feel stupid and say that a program like this already exists. After feeling stupid for a second I will be happy.
While I dread install wizards from windows, I remember hearing some hype about Zenguin Computing creating a universal installer back at LinuxWorld in August. I Haven't heard anything about this project since. Anyone have some info?
I personally have found debs to be a great package management system, but having some wizards would definately help sell linux to newbies. They simply cannot handle the command line.
And now for some PR goodness. http://www.in foworld.com/cgi-bin/displayStory.pl?990617.pizengu in.htm
Silly Dr. Sp0ng, it's just the dept. Like the Midget in Illuminatus...right? Wasn't there a guy who went around posting signs signed 'the mdgt,' and people obeyed them? Or something? So what is 'dept.' really short for?
Boy, is this off-topic...
-Ravagin
"Ladies and gentlemen, this is NPR! And that means....it's time for a drum solo!"
Karma: T-rexcellent.
Are the current Problems the result or of the package system of the pakager?
I have only experienced RPM's and find upgrades to existing packages can often install in a different directory. In particular when I upgrade from the standard RedHat RPM's to some generated by the software authors (eg E or Gnome) I get bit's of the old version left arround.
The problem is worse if I use a tarball after an RPM. I have compiled, installed then run only get the old RPM version when I was expecting the tarball to install in the same DIR.
Perhapse the answer is more standardised install guides like the linux directory structure I have heard about. If tarballs and RPM's, Deb's etc all installed the same package in the same place every time then all we need is a generic interface along the lines of Gnorpm.
Tokyo Joe
I read the majority of the comments, waiting to see someone say something nice about .debs, and you finally did.
I can't agree more--there aren't enough nice things to say about the debian package format. It is largely automatic, clean, and it handles dependencies gorgeously!
The only problem is that when something breaks, it's somewhat tricky to clean things out. Of course, it's easier than with RPM.
--
Max V.
There should be a moratorium on the use of the apostrophe.
Max V.
NeXTMail/MIME Mail welcome
- There needs to be a universal interface for managing the removal of packages, too. RPM and others take some steps in that direction, but no one really gets it right, as it always seems necessary to override the automated system from time to time as it gets "confused". This is not all that difficult a problem; there just needs to be a central repository of reliable information on program/library dependancies. The biggest problem here is that the need for *all* programs to use this system for installation in order for the system to stay coherent.
- Source-level compatibility across free Un*x variants should not require something like autoconf to build across systems. The vast marjority of details autoconf takes care of should be considered bugs in both the Linux and the *BSD development trees until they come to a common ground. Of course, this is a sticky issue, as everyone always thinks their way is the "right" way to do something, and the passion about something being "right" is generally directly proportional to the triviality of the detail.
If these problems were solved, and an interface likeThe biggest problem I have with almost every OS in existance is the gradual buildup of cruft as the system stays up for longer and longer times. Removal modularity needs to be solved and solved in a complete and elegant manner to keep systems clean.
This will probably annoy many people, but given the Un*x market share of the free OS options, and the availability across a wide range of hardware platforms, moving forward while maintaining compatibility between free OSes is probably the best medium in terms of supporting interoperability while maintaining the ability to move forward. In other words, for most applications let's just not worry about getting it to run on SunOS or SCO or Tru64; it's more overhead than it's worth, and if we're truly innovating then the proprietary unices will follow our lead.
yea, i said it does provide it but I don't ever remember seeing a replaces line. I have woody.. It won't let me replace it because there are already programs that rely on libesd0. So, it probably is the replaces line but I don't even know if dpkg would willingly purge it.. but i don't have the guts to find out. This is the main reason I hate unstable.... I also don't have any idea how to report bugs, I guess I could go to the debian page and look for email addresses but I wish there was just a program I could download that would let me enter a bug with a combo box and a textbox.
I agree with you and I like debs a lot better except for one thing: the dependancies are a pain. This package requires this, and this package suggests this, and this package conflicts with this, and this package provides this. I think it is easy to understand but the computer doesn't. Right now, I want to remove libesd0 and get libesd-alsa0 which PROVIDES libesd0 but it won't let me do it because there are already programs that depend on libesd0 and won't let me remove it. I could manually hack at it, but I'm scared that I will only confuse it more.
No Dependencies?
If you have installed a VB programme (my memory of this was in the Win3.1 days, it may no longer be accurate), it would probably need VBRUN300.DLL. (Most programmes didn't include it because it was large (~500k) and didn't change.)
There were also programmes which required CTL3D.DLL, which became obsolete with Word6 and replaced by CTL3DV2.DLL and then CTL3D32.DLL. Not to mention OLE*.DLL and COMCTL.DLL (which existed in many incompatible versions).
Win4.x games often need DirectX (in various versions) to run properly. And so on.
Because these aren't labelled as "dependencies" (ooh, a nasty long word that the average user won't understand) doesn't mean that they aren't there.
My apologies if this no longer applies.
I personally think that best way to distribute programs is in source code. Think about it a little bit, When you compile you can optimize for you processor, etc.... Now I would like to see a package distribution that was source based. Not tar or rpm. Something that compiles in the background installs, move the binaries, and libs to the correct places.
Actually the best thing I have seen so far is the ports collection for FreeBSD, extremely user friendly, all compiled all optimized, dependencies get resolved, it is pure heaven
One way to find out what files are created during an install is to just search for them.
In install directory:
touch touchedfile
make install
find -cnewer touchedfile
I think this is the right thing to do...
...)
Right now, i see developers struggle trying to find "reasonable" settings, and package maintainers have to always play catch-up.
what if:
- there were a couple of files (using xml of course) with mappings for the current and other distros/platforms (a debian mapping, a redhat mapping, BSD, Solaris,
- a standard way of asking configuration questions, independent of the installer program ala debconf, with resonable standard settings of course.
- some way to handle dependencies
... so you can install your own wacky distro in for instance this way:
* download all the universal source packages you want/need.
* make a new "mapping file" with all the settings (fs hierarchy, whatever...) you want for your new distro
* let the universal source installer rip, on all your downloaded packages - pointing to some freshly formatted and mounted drive.
* let it simmer overnight, while it compiles, configures and installs all the source packages on the drive.
* blammo, your own super-optimized/personalized distro in the convenience of your own home.
On a side note... i really like the way NextStep bundles relevant files together in a ".app" dir. It hides the files, but keeps them accessible and together.
maybe you could have something similar for source ".src" bundles. and compile them with one command to an ".app" bundle or something.
What's sure is that anything is better than what we have now. If we had a good way of handling source packages, the whole problem of standardizing linux would become a moot point, because you could just write a little mapping for whatever distro you want. Once you have that mapping you hardly need to maintain seperate packages for the distro of your choice.
This method really has quite a bit of potential. It sounds like a solid method, and a great GUI based system could be built on top of it.
It would never work on any os that doesn't have symbolic links, which is a good or bad point depending on your beliefs.
Having said that, I'd like to see some kind of universal package manager that WOULD port to other OS's easily. Something that didn't need symbolic links and had hooks for proprietary things like ini file updates and device driver installations. I'm skeptical that this is possible though, as filesystems from different OS's tend to be so different.
--- Cum catapultae proscriptae erunt tum soli proscripti catapultas habebunt
Automake already makes Makefile that has install and uninstall and it takes care of all files that should be installed into system (of course you may hack your way around this, but it's not intented that way) so generating file list for rpm shouldn't be an issue?
I haven't used .deb format but I really like uninstall via "rpm -e packagename".
_________________________
Spelling and grammar mistakes left as an exercise for the reader.
RPM users do have an apt-get-like program now; it was put up on Freshmeat recently. However, rpmfind is not quite apt-get; all rpmfind does is to check the ftp sites for updated packages (by default, it does this each night via a cron job). It cannot handle dependencies, and is not really a tool for installing new packages; it's for keeping your system up to date. I use it on 3 workstations that are still RedHat (on an X-terminal, who cares?). It works.
.deb from an existing install and *gasp* actually have a .deb file on my hard disk :)
I suppose I should have clarified the capt thing; I have read the reason they gave for removing it, but I completely disagree with them. Firstly, in using it approximately 8 bazillion times, it has sig-11'd twice (the described bug). Second, they LEFT IN aptitude, which DOESN'T EVEN WORK!! Grrr...I was very surprised/displeased when it vanished; I had to rebuild the
WMBC freeform/independent online radio.
There's no mention of building software in the OSD spec. It won't tackle the problem that the author of the editorial describes: making it possible to compile the software on heterogenous systems.
I/O Error G-17: Aborting Installation
As a rather new linux user, I 100% agree. I'm using a new Debian release called Storm Linux >> http://www.stormix.com/ .deb bundle to 4 or 5 files. When I pick the "apply package changes and quit" button, the number of files to be installed balloons to about 180! I've gone through that upgrade twice and both times it's gone quite badly in the end. Again.. like it or not, a frustrating experience to any user. OK.. Storm has a/the right idea. I applaud them! In fact, I think I'll email their support line. Maybe they can help me through this. Let's fix this and not fight about our dists differences. You have to agree that many/most people wouldn't suffer through the learning curve. It really could be much easier. Thanks... no fancy sig.
Storm Linux includes something that's a great idea and a step in the right direction. It's a package installer called Storm Package Manager. I've installed a few simple packages (in the same stable release)... each required installing under a dozen files and it worked fine (and was very easy). I've been trying to get my Soundblaster Live! card to work. Like it or not, it was working under W98 in 30 minutes. When I use Storm Package Manager, it resolves the dependencies on a rather new ALSA
Personally, I hate package managers. I don't feel comfy with anything other than tar and gzip. The reason is, I need control. Which is why I won't use GUIs unless I have to (i.e. to read slashdot).
/;tar xfz foo.tgz; cd -'. You know where everything is, and you know that you can remove it -by hand- and it won't screw anything up.
.rc files. And I can change root's profile so that rm isn't executed with -i by default (although I don't have to, 'cause I won't use RH).
I'm a slackware user (no holy wars!), and I can live with pkgtool because it's really just a glorified version of 'cd
The only exception I give to this is the CPAN module for perl. The only reason why I'm willing to use it is that I *know* I'll never remove a perl module.
I'll probably get nailed by the user-friendliness advocates. I'm sorry, I don't like macs, GUIs or mice. I think of user-friendliness as idiot-compliancy. It wasn't allways that bad, but seriously, Microsoft et al. have reduced themselves to the lowest common denominator, which is a blundering idiot. I dispise this practice, and I see it happening in the Linux community, which makes me cry. But c'est la vie, besides, I can turn off inetd, rewrite the inittab, and the
Sorry for ranting.
---
[ approaching AI ]
http://www.software-carpentry.com
Thanks,
Greg Wilson
Software Carpentry Project Coordinator
This sounds a bit clumsy, as well as having a tree of directories that go to infinity.
IMHO what Linux needs is a really well designed fileset+revision based mechanism like AIX and installp.
In AIX, nearly every file (and everything in system directories) belongs to a fileset that is registered in a database. Filesets on AIX look like this:
bos.net.tcpip.client.4.2.1.99
Which is hierarchical and is completely descriptive. The last four places indicate oslevel (4.2.1) and fileset revision (the 99th). Using commands like lslpp you can tell what files belong to what filesets. The entire mechanism is elegant and very efficient. My experience with all other UNIXes continually leaves me in greater appreciate of AIX and its superior designS.
I'll soapbox here for a minute and say one thing: Its all too common for us OS bigots to dismiss anything we know little about or don't fully realize. I can't tell you the scores of times I've heard Solaris admins rip AIX...I used to be one of them. But, after running AIX for a few years in a large environment, my productivity on it is so much higher that all other UNIXes that now that I'm away from them they all seem very clumsy. Ask any serious AIX admin and they'll probably agree.
There is no doubting that AIX is the most advanced UNIX for the administrator on the market today.
sedawkgrep
Is that a salami in my pants or am I just happy to be me?
FreeBSD seems to have met many of the author's requirements with their ports system. Might something like this work for Linux too?
Look, just give me a packaging system based on XML meta data and an API. Nobody seems to even want to discuss a common Interface. If I have a common interface and plug-able installation managers, I can make installation really, really easy. And yes, I want it to be portable to non Unices. In the meantime, I'll fight with RPM and DEB.
More information on package installation can be found by following the references in my paperl .
http://www.sei.cmu.edu/staff/wjh/DeployDesc.htm
In particular the first and last describe standards for configuration description:
http://www.dmtf.org/spec/cims.html
http://www.w3.org/TR/NOTE-OSD.html
The second of these is an XML format.
Fred Hansen
look at debian/rules .debs instead.
its like a makefile, but it builds
Combined with an RPM spec file you can integrate most source with any package system happily
-Yarn - Rio Karma: Excellent
//Red Hat Linux
/usr Really?)
//1.Download archive.
//2.rpm -ivh foo.rpm
3. su to root cos RPM's db is locked
4. read all your failed dependencies
5. Back on net, download dependecies, repeat
6. relocate RPM cos of distributors brain dead
defaults (KDE in
7. force install / no deps install
8. Pray it starts
9. use alien, treat it like a tarball
10. The only complete and easy packaging system
is an absence of packaging system, and autoconfed
source tarballs with the install replacement that
logs where the install puts it all.
RPM is so much fun when you are not using the
exact same Linux version as the packager.
/* Better yet, use Debian's apt-get tool, which automatically solves dependency problems for you. */
.deb to be made. And it doesn't help on most linux systems, since alien isn't to hot on conversion from deb
Except for Debians extreme obsclesence(sp) and bias towards free software. It takes too long for
a
/*
What about, "Beat your self with a hammer, and
wonder why it hurts?" RPM is telling you that you
don't meet dependencies for a reason.
Don't be surprised if you ignore what it says and
then things don't work.
*/
How about RPM names its dependencies differently across Linux distros? I have libx installed, but the package names differ so on one distro, it fails with a dependecy warning. Force it with nodeps, it should work. It may not - they may be more incompatible.
Some RPM's cannot be relocated.
Some RPMS from SuSE fail on Redhat, likewise Caldera, likewise TurboLinux etc.
RPM sucks. All it does is allow uninstall. Its
dependecy checking is broken.
George Russell
And you can't follow Debian Policy strictly without ending up with the Debian system. So these portable packages don't follow policy -- which is bad, and is why alien isn't The Answer. Or, they do follow policy by having all the information necessary for every OS/distribution on which they are installed. But then each author needs to know about the requirements of all the operating systems, and if the OS is changed ("innovated" :) then the packages won't really be correct any longer.
I don't think there will be a magic bullet for packages until operating systems are so commoditized that there is effectively only one. And that's a long ways coming.
A single binary package doesn't really relate to the problem at hand. The problem at hand is: how can you install a program on different systems, so it is installed appropriately to each operating system? A single binary package only makes alien obsolete, but solves none of the difficult problems involved.
Editting makefiles is far more difficult than init files. Consider how long the init file for a package is, and the length of the makefiles for the same package? The makefile is always more complicated and more fragile.Makefiles were solved first because that's the order in which things work -- programs are programmed, and only then are they worth installing. But it doesn't mean makefiles were easier.
From what advocates say, it seems like the ports system makes building a system fairly straight-forward, but I don't know how it deals with changing a system.
Can you uninstall programs with make uninstall?
Does it recognize the problem that occurs when app A requires libfoo v5, and app B requires libfoo v4? What happens when you install app A? Does it upgrade libfoo and break app B?
I really don't know the answers to these questions. Ports seems like a very ad hoc system, which isn't a great way to ensure system integrity. But as I said, I don't really know.
I get the impression this is already a problem with the various rpm-based systems. There are certain RPMs that will break a SuSE system, for instance, no?
Using RPM won't solve much. Alien already solves that problem. And, having used alien, I can see why that solution doesn't solve the real problems involved. It doesn't suddenly make RPMs compatible with a Debian system.
Which program/package controls which package? Which one Knows more about the others, and so has the wisdom to deal with installation? The problem I see in the Windows installation process is that each application thinks it's Right and does whatever it takes to make it work, even though that application is ignorant of what is necessary to make the entire system work.
I wouldn't trust any package to be too smart -- a centralized system (like an RPM database and all that infrastructure) is restrictive but can keep the system sane and make it possible to look in from the outside and figure things out. I don't see an ad hoc system (which is what you propose) capable of doing this.
Also, you could check out the GNU Stow webpage at http://www.gnu.org/software/stow/stow.ht ml .
-----
Free P2P Backup, Windows & Linux
Well, the upgrade step doesn't seem so easy. You should use one utility to update ports, second one to check if update for package exists, third one to remove old package, and only then install a new one (and God help you if new one didn't install cleanly - you are now in the cold, because old one is erased). BTW - what with config files? RPM has pretty sophysticated algorithm to manage them, that works in 90% of cases and doesn't make a mess (i.e., doesn't prevent package from working) in 95-95% of cases. How ports system handles this?
-- Si hoc legere scis nimium eruditionis habes.
Obviously you can "overcommit."
What could we propose as an alternative?
If you decide to install Balsa, which pulls in big chunks of GNOME, that may be a bit distressing. It's hardly hidden. And if you actually want to install Balsa, you've little choice in the matter.
You can either say,
- Oops. I guess I didn't want to install all that much stuff
- Pretty big, but I guess I'll have to live with that.
There's no "Oh well, I'll install bits of it that won't work" (at least not without some explicit effort!)and back out, or
Remember that in the in the "Windows World" it also wouldn't be a 300k email package. It would be a 20MB email package that includes every library that could conceivably be necessary.
And you'd have to worry that the email client might come with some older DLLs that will overwrite ones you're using for something else, thereby toasting other applications on your system.
If you're not part of the solution, you're part of the precipitate.
Then you start having to search for the #include files that the program expected to find. Which establishes that you have to install (say) a new version of ncurses or some such thing.
It may not be a full-scale porting effort, but it does require, if you want any hope of troubleshooting, being reasonably comfortable with the tool set used for C development.
If you're not part of the solution, you're part of the precipitate.
It would be a downright awful idea to create an InstallShield Package Installer tool that forcibly requires user intervention. The folks at TiVO have taken an interesting approach; they offer to do a system upgrade every day and this requires no user intervention.
After all, the only thing easier than moving from CLI-based utilities to X-based utilities is to move to cron-based utilities that don't require that the user do anything at all.
The Debian folk have been working on improved front ends for quite some time, and prototypes for the dselect replacement pop up occasionally.
Similar is true for RPM; if you actually look, you'll find tools that are actively being worked on.
But I'd still argue that if, as you say,
then the right answer is not to throw a GUI in front of it, it is rather to schedule a process that automatically grabs packages and installs them without there even being a GUI involved.If you're not part of the solution, you're part of the precipitate.
Of course, with Debian, it amounts to "Oops - you don't have the GLIBC that I need. I'll add the right library to the list of packages that I'll be downloading for you."
By the way, dselect will, after it finishes downloading all the packages you needed into /var/cache/apt/archive , and installing them, ask you nicely, Do you want to erase the installed .deb files? to which the answer, for the average user, is probably always going to be Yes.
If you're not part of the solution, you're part of the precipitate.
It works well simply becouse CPAN:
./configure, make, make install. But instead it's perl Makefile.PL, make, make install.
A) Holds the source packages.
B) Perl is mostely platform independent.
This is really no more then we currently have in most standard *nix install packages, aka,
-- I'm the root of all that's evil, but you can call me cookie..
I'm not trying to pitch it, but the package that Debian uses does nearly all of this already. This is the selling point that starting to sell me from RedHat to debian, particularly the package conflict managment. It'll tell me what this will break, how, and offer ways to fix it.
It also has command line and GUI modes, using packages such as dselect, etc.. I admin I haven't tried the X interfaces quite yet, but I'd imagine they are extremely simular to the command line ones..
-- I'm the root of all that's evil, but you can call me cookie..
dpkg should be fine with this situation if the dependencies are right -- if you remove or purge libesd0 with a --force option the worst that'll happen is that libesd-alsa0 will not install, but you'll be able to reinstall libesd0 without any problems.
I also don't have any idea how to report bugs
Have you looked at the reportbug package? I also remember reading a reference to a Web-based bug reporter, although I have no clue where it is..
Daniel
Hurry up and jump on the individualist bandwagon!
I have 0.3.18, but it's been in there for several versions. Look:
bluegreen:~> sudo apt-get --reinstall install hello
Reading Package Lists... Done
Building Dependency Tree... Done
0 packages upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 4 not upgraded.
Need to get 19.5kB of archives. After unpacking 0B will be used.
Do you want to continue? [Y/n]
(and it would let me reinstall hello if I hit "yes")
Daniel
Hurry up and jump on the individualist bandwagon!
As I said (or maybe didn't), I checked the console-apt bugs page and it looked
:-) ./ )
to me like it wasn't really a release-critical bug. So I agree that removing
console-apt was probably overboard.
Second, they LEFT IN aptitude, which DOESN'T EVEN WORK!!
As the author of Aptitude, I have to take some offense to this, particularly since I use it daily for my own package management and just finished using it to purge a lot of cruft packages from my system and perform my daily upgrade. Not too much offense, though, espcially since it has been known to break from time to time
Would you mind telling me what doesn't work for you -- filing a bug report with debbugs or Sourceforge would be favorite -- and seeing if you can reproduce it with the latest version? (0.0.6, available from Sourceforge or with the apt line: deb http://aptitude.sourceforge.net/debian
Thanks,
Daniel
Hurry up and jump on the individualist bandwagon!
I do know the difference--I currently am working on two (vaguely related) projects that link against libapt, so I'd better know the difference ;-) -- but this isn't about apt or dpkg, it's about .tar.gz, .{dsc,tar.gz,diff.gz} and .srpm (?). As you pointed out.
:) )
In any event, I agree that abstracting the packaging process out is nontrivial and maybe even impossible, but I think taking a crack at it would be nice, just
because it would be so incredibly useful if it worked. (not that I have any
time to work on it
Daniel
Hurry up and jump on the individualist bandwagon!
I know about Debian source packages. I use Debian source packages. I know how to make Debian source packages. I make Debian source packages.
.tar.gzs, debs, rpms, slps, and FooPkg packages. And personally, I think that it's a good idea *EVEN IF* it's technically impossible due to the complexity of integrating a package into an existing system. It's still something to think about as a possibility if the opportunity to do it ever comes up.
This is not about Debian source packages. This is not about RedHat source packages. This is about abstracting source packages so that one set of build files will do source installs, straight binary installs, binary
Daniel
Hurry up and jump on the individualist bandwagon!
Just to reply to you again..
/usr/bin (on Debian systems at least) and maybe some data files under /usr/share -- for example, your average weekend-hack game.
:-)
I'd like to add a brief note to my earlier reply -- abstracting the packaging system is difficult for large and complex packages, but those aren't the ones that it's really hard to keep up with, as there are relatively few of them. What this would really benefit would be packages that install a few files in
Autoconf already provides a mechanism for flexibly selecting where to install a package based (I think?) on system defaults -- for example, $datadir and $bindir -- and if used properly it *could* (er, theoretically) be extended to automatically generate a minimal proper package for various target systems. You might even get it to generate some simple package information -- eg, menufiles. It wouldn't cover every eventuality, but for small programs, or programs with simple needs, it'd be a start.
Now, the real question is, how many of these games would you trust the binaries of?
Daniel
Hurry up and jump on the individualist bandwagon!
You can reinstall packages with "apt-get --reinstall install foopkg".
Daniel
Hurry up and jump on the individualist bandwagon!
Yes, apt rocks, etc, but the article wasn't about package formats, it was about packaging: that is, how can authors create their build scripts in such a way that any package system they can target any package system they feel like?
Daniel
Hurry up and jump on the individualist bandwagon!
I like Debian, but I'm not sure the package manager is that much better; I think there's just a lot more work put into making sure packages play nicely with one another and with the system as a whole. In particular, there are a couple of nits to pick: :) ) -- joeyh's alien package will happily convert both ways. :-)
-> RedHat can use debs just as well as Debian can use RPMs (that is, not too well
-> RedHat users claim they have an apt-like program. Not having used it, I can't comment on its utility, but you should be aware it exists. (rpmfind)
-> Config file handling and rebootless upgrades are cool. Oh wait, you said that already
One other note -- if you go to console-apt's bug page you can see why it was removed from potato -- there were evidently some release-critical bugs filed against it (segfaulting) that the maintainer didn't get to in time. Whether they really should be release-critical, and whether they were fixed..I'm not sure; I don't use console-apt, so I can't comment.
Daniel
Hurry up and jump on the individualist bandwagon!
Bah, libesd-alsa0 does Provide: libesd0. I think maybe it's missing a Replaces: line, but I'll shut up now :-)
Daniel
Hurry up and jump on the individualist bandwagon!
--
Writing a tool to create one of many binary distribution formats is a waste of time. It makes far more sense for the free software community to use a single binary package utility. The analogy with autoconf doesn't hold up. Autoconf simply edits makefiles. There is no common init file for package systems that could be used in the same way.
I am perfectly happy with the way packaging system currently works. Granted, I am not an average newbie -- I've been running Linux for almost 2 years, so I may overlook something that a newbie would have trouble with.
rpms and debs make install/uninstall simple. I mean how hard can rpm -i be? Even way back when I first installed Linux (RH 5.0), I had no problem with that. Uninstall? No problem either: rpm -e. This works just as well as InstallShield, and doesn't waste download time by putting self-extracting code in every package.
Debian does an even better job. "apt-get install foo" will auto-magically *download* and *install* foo for you, as well as any other packages that foo needs in order to work. Give me an equivalent windows command for that. Similarly, "apt-get remove foo" will uninstall it.
So, I just don't see what the problem is.
What I would like to see though, is some kind of consolidation of debs and rpms into a single universal format.
Also, a GUI config tool for packages would be very nice. Newbies can get scared away by Debian's text-mode config scripts. But progress is already being made in this area. The frozen potato (Debian 2.2) already includes a front-end for package configuration.
To sum it up, package system can certainly use some improvement, but things are nowhere near as bad as the article would seem to imply. I would like to hear other opinions (esp. newbies) on the subject.
___
___
If you think big enough, you'll never have to do it.
---
Personally, I think that encouraging binary packages is a Bad Idea for the Free Software community.
---
...while a great idea for anyone who wants to use Linux/Unix to actually get work done without screwing around with compilers.
Who should be focused on? It's hard to say, although my intuition seems to go with the latter.
- Jeff A. Campbell
- VelociNews (http://www.velocinews.com)
- Jeff
---
Looks like we got a clueless moderator here.
---
Same here. Somebody re-moderated it as 'informative'.
I venture that more people use Linux as a tool, rather than a means in itself. I believe more people use it primarily for server usage (with desktop use rising fast) than as a platform with the main intent to code for. Of those that do code, do they make code-level alterations to the majority of items they download? Not likely. Most people have a few set things they like to hack on, and would rather just install everything else so that It Works.
Having the ability to compile stuff - which I agree is a 'big plus' - doesn't mean you should be forced to do so. Other than helping people gain ground on the 31337-ness scale, I just don't see why it's necessary for everything to be obscure and non-intuitive.
- Jeff A. Campbell
- VelociNews (http://www.velocinews.com)
- Jeff
As a FreeBSD user, source regen is the only way I upgrade. :)
Why not use something like the FreeBSD Ports package management toolkit? It maintaines all the dependencies. It also provides simple install and uninstall mechanisms. In fact, I have never had a package installation go sour with this. In fact, the FreeBSD package manager was one of two reasons I dropped Linux completely. It is just that nice.
Answer: because each little program spews a morass of files all over the filesystem and is near-impossible to delete by hand.
.app extension containing a binary and icons in predefined places, plus libs, config, documentation, whatever the program needs. And, for when libraries should be shared (eg:GTK) a system called "frameworks" - basically bundlesd shared libs, plus include-files, plus docs, plus whatever.
/Local/Apps and tadaaah! one program installed. To run the program, double click the app bundle.
How about instead of fussing over package manager formats, we do instead what has been a tried and tested approach to the whole business: bundle directories. A directory with a
The important point is: Joe Average never needs to know what's inside a bundle. The filesystem GUI treats them like single files. To install a program, double click the tarball and a window opens with a bundle icon. Drag the bundle icon to
Now isn't that a bit nicer?
(hint: GNUstep is already using this, and it should be fairly trivial to configure the misc binary support to run the launch script on execution of an app bundle)
You forgot "and digging out files from the system directory, and figuring out which system-critical DLLs have been written over, and clearing out the buried registry entries..."
Win32 does have an easier install process, but uninstalling is a bitch. I'm loathe to just "try out" some package because who knows what state my system will be in when I uninstall it again...
----
ldd `which ln`
/lib/libNoVersion.so.1 => /lib/libNoVersion.so.1 (0x40014000) /lib/libc.so.6 (0x40020000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
/lib/libNoVersion.so.1 => /lib/libNoVersion.so.1 (0x40014000) /lib/libc.so.6 (0x40020000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
/lib without these tools?
libc.so.6 =>
ldd `which mkdir`
libc.so.6 =>
(sorry if that came out really ugly)
Anyway, how am I to recreate
I wouldn't call rpm and deb proprietary formats, either. They're cpio and ar archives respectively.
Also, distributions could not install as quick if they had to run configure for every package they were to install.
LANS are getting more and more popular. I have one in my home. They are near ubiquitous in high tech workplaces. No matter how easy *BSD ports or Debian's apt-get is, there are economy of scale benefits of just maintaining ONE application collection, rather than a separate application locally on each machine of a LAN. It's really a separate problem space; packaging systems like DEB and RPM make installing software easier (reducing difficulty in installation). Distributed filesystems can reduce the amount of installations required (reducing redundancy of installations). What can't I take advantage of my friend's diligent use of apt-get just one IP address over? Why should I do redundant administration if I don't want to?
The next revolution in linux software distribution will be distributed filesystem friendly software collections; and I don't care if that distributed filesystem is Coda or Intermezzo or AFS or even lowly NFS. I just wish I knew the best place to throw my hat in to the ring and work on this right now. This is the one station where linux software collections have major room to improve.
This is really no more then we currently have in most standard *nix install packages, aka, ./configure, make, make install. But instead it's perl Makefile.PL, make, make install.
I think the poster above is talking about the module CPAN, which you can execute with: perl -MCPAN -e shell
This is very much like a package manager and, here I have to agree, very comfortable. Just type i.e. install foo, and foo is downloaded, compiled if necessary, tested, etc. Dependencies are taken care of too; and the shell is really nice too: you can use regexps if you don't know exactly what the package is called, and you can even read the README before you download.
That being said, I think you have a point about all the packages being at a central location. Nevertheless, I think the standardization of the module packages plays an important role too.
Chris
San Francisco values: compassion, tolerance, respect, intelligence
I have to agree. I found the ports collection to be very easy to use. In fact, the FreeBSD packages are merely precompiled ports.
One caveat, however. The purpose of ports is to allow painless compilation on FreeBSD. Since every FreeBSD is like the next, the patches and configurations work without a hitch. But how will a ports work under Linux when there are so many different distributions?
I can't even get some configure scripts to run to completion on some distros. How in the world will ports work when every distro wants to do their own thing? Will every distro have to maintain their own ports collection?
What we need long before we need ports, or the articles universal package manager, is a standard Linux. When the LSB is done, then we can start getting stuff to work properly.
A Government Is a Body of People, Usually Notably Ungoverned
"Can you uninstall programs with make uninstall?"
Yes. Just type make uninstall.
"Ports seems like a very ad hoc system, which isn't a great way to ensure system integrity."
From what I can understand listening to people who know, it's much more robust than rpm but not quite as robust as apt. It's more than just a set of makefiles. It keeps track of what's installed, what they're dependent on, etc.
A Government Is a Body of People, Usually Notably Ungoverned
"If you installed with RPM or the Debian package manager, you still have application-created data lying around."
I am unaware of any OS that deletes user generated files when the application is removed. Think about this and you'll realize what a Bad Thing that would be. Maybe when you uninstall a program you want to get rid of all your work as well, but some people don't.
A Government Is a Body of People, Usually Notably Ungoverned
I don't understand your argument against RPM/Deb's method of uninstalling.
:)
They work fine for me... never had a problem with lingering files. Anything related to it (config files, whatever) are always in ~/.<appname> if it's a UNIX-like conforming app. Therefore, all you have to do if you really want to get rid of something is removing it with your package manager, and then rm -rf ~/.<app>.
Would you prefer that the package manager erased these directories for you? I think not. Sometimes when you uninstall a package you WANT to keep this data (I do almost always). Hmm, perhaps an option to --nuke all associated files for when you want that?
Yeah, just pull it all out of context, windows is easier for most people by a long shot.
I'm not pulling it out of context. You're missing the point by focusing on my example.
Under Windows, there is structured no way to install, uninstall, manage dependencies, find out which programs own which files, or which programs need which files.
Your given example of a "Windows" install is totally bogus. For one, you totally ignored the issue of 15 different ways to distribute archives. For another, every install program is just a little bit different. Going with the defaults rarely works, or if it does, yields a system which is totally unmaintainable. Uninstalling things is a nightmare, and DLL versioning is, as is so often stated, a living hell.
I know you post to Slashdot just to be have fun as a Microsoft-loving troll, but come on! You can do better then that, TummyX!
Read RPM documentation to figure out how to use RPM.
Bah. First of all, if the user is interested in RTFMing, they are going to have to do it anyway, regardless of platform. Second of all, if you're using GNOME or KDE, you can just double-click on the package file, and it will offer to install itself. Furthermore, there is no question as to what kind of installer it will be.
Get obscure errors about dependencies you need.
I knew I should have used Debian as an example. Okay, replace all instances of "rpm" with "apt-get", and your entire argument just evaporated. apt-get will automatically resolve all dependency issues for you, including downloading the needed packages from trusted sources.
Goto redhat.com to try to find the other RPM you need.
You forgot, "Beat your head against the wall, simply because you're a Linux user, and Linux requires you to do that." Give me a break, TummyX. Just use rpmfind and it is totally automatic.
Manually make your KDE links to the files.
So the packager didn't do there job. Nothing on Windows makes an installer put links on the "Start" menu.
execute the application only to find that it depends on some other application to get XXX feature enabled.
Right, and of course, that doesn't ever happen on Windows or anything like that.
Sometimes you actually give some good insight into the limitations of Linux, TummyX, but lately, you just seem to be generating noise. If you're going to troll, at least do it right!
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
su to root cos RPM's db is locked
Okay, I forgot that, but: Good! This helps keep the virus problem to a minimum! Besides, the more recent versions of GNOME and KDE take care of this nicely, by prompting you for your password.
read all your failed dependencies
Better yet, use Debian's apt-get tool, which automatically solves dependency problems for you.
relocate RPM cos of distributors brain dead defaults
While I agree that some RPM's pick rather dumb locations for things, how is relocating them any different then from changing the default location in a autoconf-based install?
7. force install / no deps install
8. Pray it starts
What about, "Beat your self with a hammer, and wonder why it hurts?" RPM is telling you that you don't meet dependencies for a reason. Don't be surprised if you ignore what it says and then things don't work.
The only complete and easy packaging system is an absence of packaging system,
That doesn't manage dependencies for you.
RPM is so much fun when you are not using the exact same Linux version as the packager.
While RPM has its faults, I haven't found that to be one of them.
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
I don't. However, you are a Microsoft-loving troll. That is, a troll whose preferred method of trolling is to advocate heavily in favor of Microsoft, especially in Linux discussions where it is off-topic and guaranteed to raise flamage.
Like I said, sometimes you actually raise some valid points, but it gets old after awhile, and this was just pretty weak.
If it makes you feel any better, you're one of the best trolls on Slashdot. You always keep just close enough to the truth that you don't get moderated down or ignored. You even have an account with good karma, a technique well beyond the skills of your average AC.
So by my example I was showing how your example meant very little.
Ah, so we're no longer trying to argue that Windows does package management better, eh? I gotta hand it to you, TummyX, you know what you're doing. Looks like you're going to lose the debate? Answer a different question! A move from the Bill Gates playbook itself.
I was parodying your example for fun.
At least you admit it. I appreciate that.
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
I have to admit, Debian's package system is the big thing that is drawing me towards trying out Debian. (Mainly, what I'm waiting for at this point is for "Potato" to become "officially" stable.) More automatic, more features, and a better organized package achive. Gotta love it.
However, as a current Red Hat user, I figure I might as well put in a word for RPM. It manages dependencies, source, installs, and so on and so forth very well. The main thing it lacks is Debian's automatic package retrieval for dependency satisfaction (again, an awesome feature). But, if you are using Red Hat, be aware of the "rpmfind" command. The command "rpmfind foo" will search the net for package "foo" and offer to download it for you. Not Debian, but a heck of a lot better then a regular netsearch, for sure. :-)
Just an FYI for RPM users.
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
Except for Debians extreme obsclesence(sp) and bias towards free software.
Debian is actually very up-to-date. They don't follow the Red Hat model of "a stable release every six months"; they use a more dynamic system where all packages are always being updated.
And while they do favor GPL-style Open Source Software, they by no means exclude other OSS software. It just comes from a different branch of their tree.
How about RPM names its dependencies differently across Linux distros? I have libx installed, but the package names differ...
How about the fact that RPM doesn't depend on packages at all, it depends on files? Do you have a legit gripe here, or did you just have a bad experience with RPM as a child and you're not willing to see reason anymore?
Some RPM's cannot be relocated.
And some source code contains hard coded paths all over the place. A bad package is a bad package no matter how you package it.
Some RPMS from SuSE fail on Redhat, likewise Caldera, likewise TurboLinux etc.
Funny, I don't have that problem. Are you using Red Hat 3.0 or something?
What's up with you? I mean, I know RPM isn't a perfect piece of software, but you seem determined to not like it.
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
Package formats such as deb and rpm are proprietary, not in storage format (rpm's use cpio or something), but by composition and requirement. They are composed in a format that is exclusive to their own system of doing things (having specific files in the archive with meta-data about the package).
Could you please explain to me how else you are supposed to figure out this information? Any package is going to have to include meta-data about the package (or be damn hard to use, otherwise). It may be in English in an INSTALL file, but it is there. And computers are notoriously bad at reading English. Both Red Hat and Debian use .spec files which are ASCII text, human-readable, and well-documented. I don't see how it can get any better then that.
They require their databases...
Again, of course they do. The whole point of a package manager is to keep track of what belongs to what, and so on. Whether you keep that inThey also require someone specifically construct them.
I wasn't aware that .tar.gz archives built themselves magically. :-)
try extracting a deb or rpm without the proper tools...
Try extracting foo.tar.gz without tar or gzip. What are you going to do, decode the binary by hand? :-)
My point is, there is nothing magical about .tar.gz files vs .rpm or .deb files. They are all packages. They all require tools to use them, and they all contain data not easily readable by humans. The only difference is, the newer package formats are easier for computers to work with.
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
I've never used Red Hat, just Debian. Can someone please tell me why anyone should bother with a package manager that doesn't handle dependencies?
RPM does understand and manage dependencies. I suspect the original poster was referring to the fact that Debian's "advanced package tool" will solve dependencies for you. When installing, RPM checks for dependencies, and if anything fails, it complains and aborts. apt can actually seek out and install other packages to solve dependencies. This is a very nice bonus for Debian users, and something I (as a Red Hat user) wish I had.
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
While I generally agree whole-heartedly with what you wrote, I do have a couple minor things about RPM to post in the interest of being as helpful as possible to any RPM users in the readership. I generally agree that Debian's package system is overall superior to RPM, and I wish Red Hat would fix it.
RedHat packages depend on files. Debian packages depend on other packages. The advantage of this for RPM is that you can install packages, if you've compiled the libs yourself...
Additionally, this means that RPMs don't depend on specific implementations of a generic service. In other words, a properly done RPM will depend not on sendmail, but on smtpdaemon. Can Debian do this?
Upgrading the system: With RedHat (maybe *RPM?), you reboot the system with the CD/disk of the new OS version, and use the "upgrade" option.
You can do it this way, by I generally find it easier to simply mount the CD, and do a "rpm --freshen -vh /mnt/cdrom/RedHat/RPMS/*.rpm". The --freshen switch tells RPM to upgrade all the specified packages, but only if they are already installed.
Just FYI.
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
What department is this from again?
heh.
"Software is like sex- the best is for free"
-Linus Torvalds
I personally like .deb files. They are easy to use for both installs and uninstalls. However, dpkg and dselect try to be smart and won't download a package you currently have installed if you have the most up-to-date version.
I would like to see a package checking program. Something that will check the packages installed and verify all required files are indeed installed and maybe even if they are corrupted. Then, this program will either reinstall the complete packages or atleast the affected files.
Any Ideas/Suggestions?
Quack
Much nicer command then what I was using, thanks, I will use it in the future - however, my point still stands that it's arcane to use. You shouldn't have to put thus and such into it to get information out like that - there is nothing as structured as APT that I know of, I was using that to find where a certain library file was located that was required by another RPM.
.sig: File not found.
In addition, yes, I'm doing an end run around RPM and yes, it's the wrong thing to do. By stating that I was merely pointing out (without saying it, as I'm prone so often to do) that in order for rpm to be more universally accepted it has to be more supported by the distros. LinuxPPC Dev Release 1.1 came out...last week I think, and it's binutils is at 19, vs. the 27 I last checked for.
That's all I'm really saying.
ls:
ls:
(A)bort, (R)etry, (I)gnore?
My issue with the article begins with the third paragraph:
t -using-the-ports-collection.
The number of package management systems is very large, and it is neither possible nor desirable to standardize on a single one.
Why is it neither possible nor desirable to standardize on a single package management system? I have been extremely happy with RPM as a basis for package management. It's vendor-neutral, architecture-neutral, compresses nicely, provides for both source and binary package types, and provides for building from pristine sources. What could possibly be wrong with that?
I get the feeling that what he's shooting for here is a way to create a single specification file to be used with a tool to create binary packages for all architectures, and all package managers. In this way I could theoretically build a Linux RPM, a Linux DEB, a Solaris pkg, and a FreeBSD whatever-the-hell-package-format-they-use-when-no
My point of view is, "why bother?" It seems to me that implementing RPM (or a similar format, perhaps with extensions to handle dependencies like DEB does) is the logical way to go here. One spec file can already create packages for multiple targets.
As an aside, I believe this paper is a perfect example of a demonstration of how as a community, we seem to suffer from multiple-personality syndrome when it comes to our software and tools. Do we let the various options duke it out in the "marketplace"?, or do we standardize for interoperability and easy configuration management? Both have their merits, but I chose RPM at my workplace because I think at this point it's the "best of breed" when it comes to package management and software distribution, and if I had to choose a package management system for every OS, RPM would be it.
Well, right now you can do this: /var/cache/apt/archives
scp friend:/var/cache/apt/archives/*
Later, you might wish to have both apt sessions run through an http proxy server (such as squid). For example:
export http_proxy=http://friend:3128/
As for the installation questions, non-interactive debconf backends are being worked on, but even that won't be a timesaver for 2 machines. Just answer the questions :)
Macintosh users (especially newer iMac users) are not going to put up with complex/user intensive installers. I know that Apple is using part of the Next-ish .App directory idea as well as /usr, /lib, /bin, etc directories, but they are also doing their best to hide this from the end-user. Does anyone know how Apple is handling installation issues in Mac OSX? Could the same approach be used to install/pkg software for Linux?
Your points are all good, but the bottom line is that I've been in this biz for quite a while, and I find autoconf pretty daunting for the average project. That needs to change. Yes many of the problems are hard, but they need solutions that present ease-of-use for the general case. autoconf does not do this.
Good points; lemme see:
/conf) and look for say /conf/apache/main.xml and then source.path or something. Then it will know how to compile itself w/o having to be told --with-apache=...
/conf. The module's developer wouldn't have to worry about a GTK interface or a KDE one or one in Lesstif or or SVGAlib... One parser/GUI to rule them all ;-)... One library to parse config files... Take the grudge work out of the developers and let them create utilities/applications.
;-)...
a)Yes, in the begginning you would solve the same problem --figure out where everything should go. But when you do put the 'meta-structure' into place, you won't have to do it ever again. A RedHat distribution's meta-structure should have the same data as a Debian's, as a home-brew. On any CPU.
b) OK; I may have not been totally clear; no application should hold information about others. It should only contain information about itself. So, if it does make the wrong assumptions, it will only break itself. For example, say you're installing an Apache module. The module installation will go to the central depository (I favor
But that's just replicating existing functionality... Think of how easy it would be to build a universal GUI for *anything* on top of
The Windows way is flawed: the Registry is not human-editable (at least not easily) or intuitive. The dll's have to be centralized and get all mangled up. Unix can leapfrog Windows now: XML config files, and well, symlinks
What I am proposing is a redesign (which I know will be a pain in the ass during the transition period). What we have *now* is an ad hoc system --which doesn't work.
engineers never lie; we just approximate the truth.
The problem with current Unix systems is not just the packaging; it's configuration. Unix's great strength is its flexibility, adaptablity, and yes its own bizarre OO-design (everything's a file).
/etc files). I propose (and have, again and again) XML.
/etc or a /var or an RPM database. What it does have is a way for you and *all* the software on your system to introspect, and find out properties of other software on your system (via some secure mechanism, of course).
When you have something that flexible, you need to account for all the different configurations and setups people can and will make to the system. That's what autoconf does for builds and the package managers are trying to do for installs. But that's solving the wrong problem: you're effectively solving a design issue with workarounds, with duct tape and paperclips.
What needs to be done, is for Unix/Linux to apply what years of experience have taught 'hardware' engineers: when you have flexible configurations, you need a configuration management system. The RPM database is not enough.
What we need, is a registry-like, centralized repository of information about the system, in a standardized language that: a) can *very* easily be read by software (a la Registry), and b) can as a last resort be edited by humans with minimum tools (a la Unix
Imagine you're working on a system that doesn't have an
Thus, a new package can find out where it can install itself and how to link to everything it needs, without messing with system-level software. Not only that, but since the meta-information for everything is gonna be sitting right there, the software can not only resolve dependencies but also suggest configuration changes in its dependencies! And since all that will be in a parsable structure, you should be/would be able to go on the Net and find out the answer to the exact problem.
Just dreamin...
engineers never lie; we just approximate the truth.
Debian (.deb) packages contain more than just files and a list of dependencies. For one thing, the menus in your window managers are updated automatically. On a more general level, some packages have scripts which run when they are installed. E.g. the glibc 2.1 package checks if you are upgrading from glibc 2.0 and if so it restarts the services on your machine which may be affected. I imagine rpm can do things like this, too.
Besides, there are more incompatibilities between different distros than just package formats. Configuration files often need to be kept in different places, particularly init scripts. The Linux Standard Base may help in future, but for now the differences are there.
I'm not saying that GNU Stow couldn't be part of a Grand Unified Solution, just that there's more to modern package management than archive formats.
perl -e 'fork||print for split//,"hahahaha"'
dpkg --purge foo
This will remove all files associated with foo, including config files. It won't remove data files you've created; this is good. (Imagine if uninstalling Word removed all your Word documents!)
WARNING TO NEWBIES: You probably DON'T want to do this. Instead do "dpkg -r foo".
perl -e 'fork||print for split//,"hahahaha"'
I think you mean ~/.
perl -e 'fork||print for split//,"hahahaha"'
I don't know much about rpm. But in Debian you can get a list of available packages and highlight items on this list and the system will install them automatically.
There's a few issues with this list. It is very long (thousands of packages) and has lots of stuff like libtiff which would only be installed because another package needed them. A newbie doesn't need to see these libraries, just the "actual programs". But all in all, it's easier to install a Debian package than a Windows program that uses InstallShield (as other people have pointed out).
perl -e 'fork||print for split//,"hahahaha"'
> When you go to download some Windows software you get a single .exe to download and install.
[...]
> For linux software we already get to choose from half a dozen different packages
This is a non-issue for the end user, because nearly all popular [freely-distributable] software for linux is available on your distro's CDs / ftp site. The user doesn't need to worry about the format, because the distro handles it cleanly.
Of course, things aren't that simple if you want software which isn't freely-redistributable. But AFAICS there's no way to clear this up without abandoning shared files altogether, or risking the kind of corrupted mess which is possible with Windows packages.
perl -e 'fork||print for split//,"hahahaha"'
I think the original poster meant "to (handle dependencies like Debian does)" not "(to handle dependencies) like Debian does".
But a package manager that didn't handle dependencies would still be useful, to do clean uninstalls.
perl -e 'fork||print for split//,"hahahaha"'
While I can offer absolutely no insight into a feasible way to make this situation better, I agree that the biggest aggravation in package management isn't installation, it's management of already installed packages, including uninstallation. Now don't get me wrong, while the windows approach to this is 'easy', I by no means consider it good. Registry entries all over, failure to remove files, overwriting of system DLL's, etc. But I for one would be ecstatic if someone would figure out a better way to manage already installed packages.
Have you guys heard of makeself? It creates self extracting and installing files(tar.gz or tar.bz2). It just tacks on a 30 line BOURNE shell script to the specified archive, and viola.
Get it here http://www.lokigames.com/~megastep/mak eself/
Dom
I've talked about a gtk applet that would use XML backends for describing various things. It'd be an extensible control panel.
:-)
The principle was that there is a root run daemon that monitors PS and measures how often certain programs are run. This would allow a person to choose little used programs to be removed.
Another part of the add/remove "front end" for the control panel would be installation. I talked with the author of gxTar (see freshmeat for it) about the install principle. It would involve untarring to a temp dir, and analyzing the output of configure --help. Then, the user can use "default safe" values, or change then via a wizard or dialog. For rpms, slackware tarballs, and debs, you could just use the the preexisting methods for checking files. For the GNU/autoconf, you could use something like the locatedb functionality for monitor what was added to the filesystem.
This allows a nice centralised install and remove functionality, regardless of packageformat, and can be extended to handle more and more package formats. It also allows you to remove what you don't use. So if you go window shopping on freshmeat and install hundreds of applets, you can prune away what you don't use after a few weeks.
Well, just some ideas of mine
---
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
Free software has two things going for it in this case. First, there is a long history of evolution rather than completely scrapping good software. There is no reason that the best solution can't evolve from the partial solutions that already exist, just as CVS was built as a new set of tools on top of the perfectly good RCS file format and initially even used RCS under the hood.
Second, there are a number of good tools that already solve parts of the problem available in source. Anyone with an interest in solving this can go to it. It sounded to me like a proposal to start developing a new tool. I look forward to seeing the prototype.
The net will not be what we demand, but what we make it. Build it well.
Yeah, just pull it all out of context, windows is easier for most people by a long shot.
....
Windows
1. Download self extracting exe.
2. Double click on exe.
3. Read dialogs, go with defaults.
3. Wait for install to occur.
Red Hat Linux
1. Download archive
2. Read RPM documentation to figure out how to use RPM.
3. rpm -ivh foo.rpm
4. Get obscure errors about dependencies you need.
5. Goto redhat.com to try to find the other RPM you need.
6. Eventally find them on some other website.
7. rpm -ivh foodepend.rpm
8. rpm -ivh foo.rpm
9. Get obscure errors about dependencies you need.
89. Finally installed, you have to figure out where the binaries were installed.
90. Manually make your KDE links to the files.
91. Finally, execute the application only to find that it depends on some other application to get XXX feature enabled.
The FreeBSD ports system is really easy to use. First you can look for a port you want to install. Say I want to install an irc client:
cd /usr/ports && make search key="irc" | more
This will give me a list of all different ports/packages that contain "irc" in the name. I see bitchx, so I type "cd irc/bitchx" then "make install clean" (I clean to remove all of the object files I don't need.) This will install any dependencies that I may need to run BitchX as well. There are a few "meta-ports" such as KDE or apache13-php4 that will automatically install and configure several ports that you would normally have to combine by hand.
After a few months I may want to update my bitchx port, so I install cvsup ("cd /usr/ports/net/cvsup-bin && make install clean"), cvsup my ports tree (check the FreeBSD handbook, or edit /usr/share/examples/cvsup/ports-supfile and "cvsup /usr/share/examples/cvsup/ports-supfile") to get the all new ports tree.
Now that I have this nice new ports tree I will need to see if the version of bitchx has been upgraded. I can use the pkg_version utility (in 4.0-CURRENT, not sure about earlier versions, I think it was a port) and type "pkg_version | grep \<" to get a list of all my packages that are out of date.
I notice that bitchx happens to be out of date, so I pkg_delete the old bitchx and "cd /usr/ports/irc/bitchx && make install clean" to get the new version.
The ports system even handles multiple versions of FreeBSD. Some packages may only run under the 3.x and earlier branches, but haven't been properly fixed and patches for 4.0-current, so they will be marked as broken in -current in the makefile, and will be uncompilable for users of current unless they want to fix the port.
If you need to reinstall a port that is the same version as the current port version, make && make deinstall && make reinstall will do the job.
Looking into the future, The FreeBSD Project is hoping to replace the current ports architecture and replace it with something even better. Shorter term solution may include changing the current directory structure and flattening it down to a category directory with a Makefile that will fetch the necessary directories it needs when you type make <portname> to save on download and install time.
marotti.com
One thing that some of you linux "gods" forget about is the usability action for newbies. This is why I fully support things like RPM and think that they should be expanded as well. However, there is a point where the newbies must learn how to do stuff as well, and RPM type things really don't teach much except rpm -Uvh and rpm -e :)
:)
One thing that i propose is that once there is a good, unified standard, that it gets CLEARLY and CONCISELY explained as far as its usability is concerned. Then after that have more in-depth faq's for you pros. Just don't leave out the newbies, please. Linux community won't grow without them, as much as some of you hate this fact
- Mike Roberto
-- roberto@apk.net
--- AOL IM: MicroBerto
Berto
Thre is an undeniable niceness to grabbing a zipfile, unloading it into a temp directory, running the program for while, deciding whether to keep it, or to delete the directory.
./configure && make && make install has done wonders for me. If you want really horrid dependency problems, try tracking down a COM object with the wrong version number - I've spent hours wading through hex GUIDs in that poor design choice known as the registry before, and come up with nothing. And these are binary-only releases, mind you.
/usr/local/enlightenment, and the beast was "uninstalled".
You've just described the relative benefits of precompiled binaries, *not* a particular packaging or installation system. Dependency-foo and Gnu-make-foo (both required elements of the broader unix-fu) are mainly products of the make system, the quality of code, and the nature of compilation in general.
As a windows refugee for roughly 1-2 years now, I can tell you that software installation under linux is the best I've seen. I can't speak for packaging systems, but the simple
Under linux, the first "package" I built was enlightenment. I read the INSTALL file, ran the requisite compilation commands, and started up enlightenment. I inadvertantly forgot to install the PNG library, so: rm -rf
The Unix "concept" already has really nice installation facilities without binary formats and RPMs. They're not graphical, though, which makes me wonder if the average user will *ever* feel comfortable using them.
43rd Law of Computing: Anything that can go wr
The package name for this is console-apt. It's a colorful, curses front-end to apt, and it ROCKS MY WORLD.
:) I was happy when I found apt, but I still didn't have a way to figure out the name of the package I wanted to apt-get, save firing up a web browser and doing a search.
.deb for you (assuming you're using potato).
There is also gnome-apt, which is a really nice interface, though you need to run X to use it (so I prefer capt for servers).
I personally think dselect is a piece of junk, and that's what kept me away from Debian at first (my first Debian install was on a 68k Mac--talk about an unfair experience on which to judge a distro!
Capt was sadly removed to potato due to some bugs that were (IMO unfairly) classified as release-critical. If you can't find it, email me and I'll make a
WMBC freeform/independent online radio.
I was a RedHat user for about a year. Now I use Debian. I'll try my best to explain the differences as I see them.
.debs.
:) If you try Debian, don't use dselect. This is my opinion of course, but I think it's a horrible piece of junk. After the base install and reboot, immediatly quit dselect and use apt instead. Sadly, they've removed capt from potato (I can't figure out why), so you will have to try to find this wonderfull tool (I can give you a .deb of it, if you want).
One important thing to remember is that while the Debian package system is dpkg, most people use (and praise) apt, which is a front-end of sorts. Oh, and Debian can also use RPM packages; I'm not sure if RPM-based distros can use
1. Dependencies: RedHat packages depend on files. Debian packages depend on other packages. The advantage of this for RPM is that you can install packages, if you've compiled the libs yourself (eg, OpenSSL w/ RSA), though you can simply force Debian to install the package anyway. The advantage of apt is that it can say, "You need these other 3 packages to use this one. Want me to get them and install them for you?"
2. Getting packages: With RedHat, you go and download your packages, and install them. With apt, you provide it with a list of FTP sites, and what categories of packages you wish to use from those sites (including which version of Debian). You tell it:
"apt-get install foo"
and it checks the FTP sites for foo, does the aforementioned dependency magik, installs it, and cleans up after itself. Oh, and it has you configure the package AS YOU INSTALL IT, which I see as a big plus. With a graphical apt interface such as capt (ncurses), you can browse the list of available files in a nice colorful interface.
3. Upgrading packages: When you upgrade a package, you don't want to overwrite the config files. RPMs either keep your config. files, or move yours to a "config.something", and use theirs. Regardless, they do what they will. Apt asks YOU what YOU think ought to be done:
use the new one
keep your current one(default)
show the differences
If you keep your current one, it saves the new one as "config.dpkg-install", just in case you change your mind later.
4. Upgrading the system: With RedHat (maybe *RPM?), you reboot the system with the CD/disk of the new OS version, and use the "upgrade" option. I've heard mixed results.
With apt, you edit the ftp sources file and change the Debian version (from "slink" or "stable" to "potato", for example). You then do:
apt-get update (refreshes your package list)
apt-get dist-upgrade
In my experience, this has always smoothly upgraded a system. Notice that rebooting is not involved; this is done while things are running, and it suggests at the end that certain services be restarted, and offers to do this for you.
I hope this helps; I can't think of anything else right now. Personally? I've found apt a lot more "pleasant" to use than RPM, which is why I made the switch. Oh, there is one last thing, which is less a difference in distros than philosophy:
RedHat install: Select your packages. Install them. Reboot and enjoy.
Debian install: Install base system, configuring networking and kernel modules. Reboot. Using your new minimal system, install the packages you need.
OK, one last LAST thing
WMBC freeform/independent online radio.
Slackware owns j00
Looks like we got a clueless moderator here.
That post is on-topic, expresses a valid opinion, uses no offensive terms, no bad language... Is it a troll just because it was posted on "Troll Tuesday"?
Anyway, maybe I'm a troll as well, but I agree with this AC. Since we all praise so much Linux and Open Source, why do we need package systems? Linux is Open Source, we are able to compile everything, of course. Why throw all this away by using a package system?
From the /. moderator guidelines: If you can't be deep, be funny
The problem isn't developing a universal format, it's in getting everyone to support this format. I think a really good solution is already available in the OSD standard. It's a standard developed by Marimba, Microsoft, Tivoli, and Novell which has been submitted to the W3C.
It's designed to be vendor neutral, and it's been written by firms that know a lot about installing software (in particular Marimba and Tivoli bear some focus).
The other nice thing is because it uses XML it's completely extensible.
Of course, the big problem is getting everyone to support it!
sigs are a waste of space
Unfortunately, that isn't all that suitable for "naive lusers" who will react to this with a big Huh?!?
Rather than GNU Stow, I'd think the direction of BSD Ports would be suitable; that provides the merit of automating the process of setting up configuration info for lots of packages that hasn't yet been done with Stow. You may want to believe that
I remain quite skeptical, as it has taken years for distributions like Red Hat, Slackware, and Debian to become richly functional.Note that Ports, like Stow, uses nothing that anybody gets tangled into thinking is somehow "proprietary." (Not that RPM or DPKG actually use anything proprietary; it's mostly Slackware bigots, with emphasis on bigot, not on Slackware, that claim, dishonestly, that RPM/DPKG are somehow proprietary formats...)
But that misses the point.
Your proposal may be suitable for you and I, albeit marginally so, as I'd much rather that the administration of package installation for the 99% of packages where "default is fine" be dealt with by someone else; it is NOT, by any stretch of the imagination, suitable for making Linux deployable in other than highly UNIX literate environments.
If you're not part of the solution, you're part of the precipitate.
I don't see any realistic way around the consideration that Systems Integration Is Messy.
Whether we talk about DPKG, RPM, or BSD Ports, it's a given that the process of getting packages integrated into a particular distribution is a somewhat messy process. In all cases, there is some form of patch that gets applied to indicate precisely how they are to get installed.
It is getting increasingly common for Debian packagers ( e.g. - the human being that builds the patches required to integrate the package in with Debian) to have some degree of involvement with the "upstream" production of the original, authoritative source code tree.
When this happens, it is not unusual for there to be a ./debian subdirectory containing the "Debian-relevant" patches, and I've also seen ./SPECS directories with RPM .spec files. In cooperative development efforts, this is the point at which important cooperation takes place, as this means that there is some thought to systems integration in the original source code tree, which will make the job easier for everyone else.
It's not likely that the level of effort will actually diminish to zero, but if it becomes largely automated, and the human effort can be widely distributed, that makes the task not too herculean.
If you're not part of the solution, you're part of the precipitate.
I thought the same thing, untill I started using debians package manager. I still use RedHat on most of my machines, simply becouse debian can tend to stay in development forever, but once they come out with potato, I'm there..
It's the difference between a 10 speed and a Harley. Particularly the conflict managment, aka, you install package A. When you select it, it detects problems with package A, B, and C, which would also need to be upgraded due to conflicts, and gives you the ability to update them as well. And the package manager also handles updates as well, that puts RedHat's up2date and gnorpm using web search to shame..
-- I'm the root of all that's evil, but you can call me cookie..
Well, part of the problem is the lack of consistency between "UNIX-compatible" platforms. In particular, take a look at Motif; "Where's Motif" is a game somewhat like "Where's Waldo", except that it's not actually fun - OK, is it in /usr/dt, or /usr, or /usr/X11, or /usr/X11R N, or in some random location for third-party packages (although the "I installed package XXX in some random place" problem is generally handled in autoconf with a --with-XXX= YYY option)?
Note the quote at the beginning of the autoconf Info file:
autoconf is trying to cope with the chaos.
"Is this Red Hat 6.1 or later" isn't a capability; presumably the package cares because RH 6.1 or later behave differently from some other systems - but the package presumably cares about some particular difference, and that'd be the capability you'd want to check.
The API would, of course, have to be independent of the questions you ask it, so that arbitrary questions can be answered, perhaps with "I don't know" as an answer; the set of questions a package might need to ask about the system on which it's being built/installed is open-ended, so you can't just come up with a fixed set of questions that suffice for all packages.
Given that, either it would have to be able to somehow deduce the answers to those questions without the cooperation of the system - which means, in effect, reimplementing autoconf - or it'd have to assume that the OS and the third-party packages installed atop it would supply those answers, which would require that the OS know about this mechanism and come with answers and that third-party packages know about this mechanism and use some other API to supply answers.
(This would also require that programmers using third-party package X for their software be able to find all the questions to which third-party package X supplies answers - and hope that they don't need to ask a question about that package to which the third party in question failed to supply an answer.)
Perhaps something along those lines (although not necessarily using an API of that sort) will come out of the Software Carpentry competition. (And, if so, it'll use Python, as per the rules of the competition.)
Unfortunately, many projects aren't necessarily "average". Ethereal, for example, doesn't "require" libpcap, it just disables packet capture if it's not present (and it has to go through some pain to try to find it); it doesn't "require" UCD or CMU SNMP, it just disables fancy dissection of SNMP packets if it doesn't find either of them, and it attempts to work with either of them; and it doesn't "require" libz, it just disables reading compressed capture files if it doesn't find it, and it requires not just libz, but a version of libz with particular functions in it, in order to support reading compressed capture files (as it doesn't just read the capture file sequentially).
Bruce
Bruce Perens.
Much as you may not want to admit it, this is one area where Windows products literally kick the crud out of the various free os's (osii?)
Not that there aren't any number of post-installation problems that can cause nightmares for Windows users; but generally, the installation of new software tends to go extrememly smoothly. This really doesn't have as much to do with MS as it does with InstallShield being the default end-all-be-all of installer builders for WinTel software, though some of the installer support included in W2K looks exceptionally neat, and a year or two ahead of what's available on Linux.
Your average user, when faced with RPM, DEB, tarballs, and the like will look at you and wonder what kind of crack you were smoking to come up with all these different ways to do the same thing, when all they want to do is just get something on thei machine so they can do X...
"Great men are not always wise: neither do the aged understand judgement." Job 32:9
We already have a very good packaging system. Want to install something and everything it depends on?
# apt-get install foo
Want to remove some software?
# apt-get remove foo
Want to hack the source to something?
$ apt-get source foo
Want to compile your own debian package from source you've just downloaded and/or tweaked?
$ debuild
And given the large number of packages available, I don't even bother checking whether the package I want exists first, 80% of the time it does.
Not that there aren't any number of post-installation problems that can cause nightmares for Windows users; but generally, the installation of new software tends to go extrememly smoothly.
Not in my experience.
Windows- Download archive.
- Figure out if it is an archive or a self-extracting archive with a fully installed program inside or an archive or a self-extracting archive with an installer inside, or simply an all-in-one installer/archive, or maybe one of those rare single-file executables not archived at all.
- If needed, extract the above-mentioned archive until you find an installer to run.
- Run the installer.
- Read the welcome message.
- Close all your other running programs.
- Read the license agreement. Jump through whatever hoop is required to prove you agree to it.
- Click "Advanced" or "Custom" because "Typical" never works.
- Redirect the installer to the "Program Files" directory on the drive that actually has free space on it.
- Watch the pretty progress bar.
- Read the readme, release notes, etc., etc., it throws up without asking.
- Reboot.
- Wonder why Random Unrelated Application suddenly doesn't work anymore, until you realize that the first thing overwrote some important
.DLL in the C:\WINDOWS\SYSTEM folder without asking.
Red Hat LinuxThere is a key difference between perceived ease-of-use and actual ease-of-use. Just because the installer has a pretty GUI with lots of colorful icons and progress bars doesn't mean it is actually any better. Give me RPM any day.
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
However, there is a point where the newbies must learn how to do stuff as well, and RPM type things really don't teach much except rpm -Uvh and rpm -e :)
While I agree, as someone who knows a lot more then how to type those commands, anything that makes my life as a system administrator easier is a Very Good Thing. If I can install a package in a single RPM command (as opposed to reading the INSTALL file, diddling with configure options, and doing three different make commands), I'll gladly take it.
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
What Linux needs is a way to uninstall applications. I don't mind compiling and installing stuff, or using .deb or .rpm packages, but I want to know that when I get rid of stuff, it gets rid of stuff.
Currently, uninstall options aren't all that promising. If you installed with 'make install', then good luck. If you still have the source around, maybe you can read the makefile and find out what went where. If you installed with RPM or the Debian package manager, you still have application-created data lying around.
I think most people have had the experience of doing a 'ls -a' in their ~ for the first time in a while and finding megs of old config data. When I uninstall enlightenment, I want it to take all seven megs of it's config info with it. Same goes for gimp or KDE.
Now, I long for what might have been if metaconfig had taken off. autoconf just isn't what it was craked up to be. There are an awful lot of one-off hacks that have no real internal consistancy. I once made the mistake of asking someone how I locate the Motif libraries in autoconf. I got several answers from "it should be where X is" to "you'll have to write your own command-line arguments, try doing something like what EMACS does". Granted, Motif is not at the heart of free software coding, but it seemed odd that a) such a popular library was not easy to locate and b) there was no standard way to say "search in these directories or as directed by these environment variables/command-line args for this library containting these headers and these functions". Many pieces of this exist, but none of it's coherent or complete.
I'd love to see two things:
If someone were to ask my opinion, it should probably be based on one of the popular scripting languages (e.g. Perl, Python, Scheme, etc).
Realistically, your average project should not have to look like more than:
buildmode: gnome_coding_standard
require: c(ansi,longlong), gtk
build_lib: fizzle(fizzle.c)
build: fazzle(fizzle, fazzle.c)
That would indeed be sweet.
The average computer user simply can't handle the command line, let alone compiling things or even extracting files from a tarball. If we want a Mainstream Linux Desktop, we'll need this type of install utility.
"You ever have that feeling where you're not sure if you're dreaming or awake?"
"You spoony bard!" -Tellah
PkgMaker is a tool I've written that can build packages for Solaris, HP-UX, binary tars, and RedHat RPMs. It uses a very simple model and can be easily extended for other package managers.
In writing PkgMaker I came to the same basic conclusions as Jeff did: adding a small amount of packaging information to a project's source would go a long way towards making packages easier.
Personally, I think CPAN makes a great model for what an end-all be-all package manager should be. Anything that handles dependencies and downloads automatically would be nice, but CPAN works SO WELL...
--- Cum catapultae proscriptae erunt tum soli proscripti catapultas habebunt
to the best of my knowledge, I am not aware of any linux distro that has an entire source tree structure such that you can 'gen a system' entirely from source - and painlessly, too. I think linux could benefit from freebsd in some ways.
I like having the ability to get just the binaries (pkg) as well as having the binaries be gen'd from source ON MY SYSTEM. no possibility of version skewing here!
so since linux can't decide on a common pkg scheme, why not take a slightly more neutral approach and just adopt the freebsd pkg/ports system?
--
--
"It is now safe to switch off your computer."
Right idea, wrong tool. See encap http://encap.cso.uiuc.edu. Stow and encap were developed completely independent of each other, but came up with the right idea. The difference is epkg, the current encap implementation, is far more featureful and far faster than stow. It's really a generation ahead.
I use RPM on a linuxppc system. The majority of my problems come when there a ppc rpm for the most recent version of, for instance, binutils. I'll do a make and make install and *boom* suddenly it overwrites the rpm's files. Oh, but wait, some are in /usr/local/bin, some are in /usr/bin. Oh, and the rpm still thinks it's installed. Oh, and how do I now upgrade the rpm, or remove it without deleting the new binutils?
.sig: File not found.
Just a few comments (also, rpm -qpl should put a header, so I can do rpm -qpl * instead of for x in *.rpm; "rpm -qpl" "$x" > "$x.lst"; done)
Jezzie
ls:
ls:
(A)bort, (R)etry, (I)gnore?
... show off one of my linux systems to a Windows-literate friend. Not a complete newbie, but someone who is used to downloading shareware and freeware utilities for Windows. Invariably they ask what the equivalent of of self-extracting .exe file is.
Now you and I may be happy with a uuencoded shell script, or wading through the 31 flavors of rpms on rpmfind.net, but coming from the Windows it looks very alien. Thre is an undeniable niceness to grabbing a zipfile, unloading it into a temp directory, running the program for while, deciding whether to keep it, or to delete the directory.
No dependency-foo, no Gnu-make-foo, no glibc-foo. Just unpack it and go. No silly compile from scratch and hope you have the right kernel, libraries, compiler and support packages.
RPMs, DEBs, source distribution with autoconf all give the user a LOT of power and niceties. But it is still an order of magnitude more complex than InstallShield looks to the average user under Windows.
Just some thought for food,
-- "Vote Democrat. Because the current crop of conservatives are just bugnut crazy."
What needs done is much simpler. Currently popular packaging systems need dumped in favor of GNU Stow. Then we don't need to change automake and autoconf at all, because they work as-is.
Dependencies could be added to Stow by someone without a lot of trouble.
For those who don't want to download and install it to figure out what it does (althoug you should! It makes life very easy if you do any source installs), GNU Stow takes "packages" that have been installed in the standard manner (things placed properly in bin, lib, man, etc.) in their own directories (such as /usr/local/stow/) and makes links to the parent directory's bin, lib, etc. You can tell by a simple ls -l what a file belongs to. Since the links in the directories aren't the "real" files, you can delete and restore them with minimal trouble (I challenge someone with a conventional system to rm -rf /lib and restore it, without rebooting). You can even maintain multiple simultaneous versions of packages. Autoconf already makes this easy to use, simply supply the --prefix= parameter to your configure scripts.
No silly proprietary formats, nor waiting for someone to come out with the latest package in your favorite format, no trying to convert foreign packages to your system. Everything you can find in a tarball is now pre-packaged and waiting for you to install...
Don't think of it as a flame---it's more like an argument that does 3d6 fire damage
This solution is very similar, but a little different to the /usr/ports solution in BSD. It would be easier to build this autoconf idea on top of ports than on top of the existing package managers, because they're already very similar.
/usr/ports/graphics/gimp ; make install" and away it goes--it downloads gimp from wherever it needs to, notices that it depends on GTK so it downloads that, etc., and builds each thing it needs in a giant make script until the whole thing is installed on the machine.
/usr/ports solution.
Brief intro for those unfamiliar with *BSD: To install "gimp" on FreeBSD you do this: "cd
The FreshMeat editorial makes it sound like this is a brand new cool idea--it's not, all of the *BSD's have worked this way for years. I really like it.
I would love to see Linux support something like this. The closest is Debian's apt, which has a mode for fetching and installing from source, but it's not as simple and direct as this
Some comments on this way of doing things:
-- I *love* being able to browse through the filesystem to find out what packages I could possibly install. It's a very natural thing to do: if I want to browse graphically, I do so via netscape or some filemanger. Mostly, being a geek, I use "ls", "cd", and "locate" to find out what packages i might want to install.
-- It's less to learn. If you are already going to have to learn how to do "make install" in order to get packages installed outside of your package management system (you just HAVE to have the version released yesterday) then you have already learned what you need to know to install any other package.
-- It does support a binary packages system. Binary packages amount to doing the compile stage on someone else's server, the whole install process goes exaclty the same way except that ratehr than compiling the binaries, you fetch them.
-- It brings everyone closer to the source tree. It's natural to grow up from being a novice user, to being a bit of a code hacker. There the code is, in front of your face, begging you to look at it--many people say this will scare people off, but nothing *requires* you to look at the code; and it's incredibly tempting for the curious. I think this leads to more developers, and is the main reason why *BSD has been able to keep pace with Linux despite having many fewer users.
-- The filesystem is a concrete, easy to understand organization for the packages. I can visualize where things are and how they relate to one another. With other package managers, like RPM or DEB, the dependencies seem complicated and abstract. When there is a failure, I haven't got a clue what to do (well I do now, but I didn't used to). AT least with compiling when there is a failure I can kind of see that it is a file in this package that lives over here, and that is causing my problem. I may not know what to do, but I know where the problem "lives". This makes me a little more motivated ot try and fix it, possibly by trying to install that other package some different way or something. In theory deb is the same, but it just doesn't *feel* the same.
In my opinion the only package management approaches that anyone should seriously consider are the Debian approach (apt/dpkg) and the *BSD appraoch (ports, plus their package management tools that back it up). Both of these allow all kinds of fun stuff like upgrading your system live without rebooting; synchronizing on a daily basis with the most current version; and have intricate and strong concepts of dependencies between packages.
In theory, they are functionally equivalent--or close enough--but I prefer the filesystem based implementation that has source code at its heart. It not only seems more Unix-like to me, it seems more open.
The big counter-argument to all of this is that source is scary to average users, many of whom don't understand the filesystem at all. I figure this is no argument at all, because you can bury the compilation under a pretty GUI just as easily as any other dependency system. And if your user can't figure out a filesystem, they won't be installing stuff using *any* package manager: it'll be pre-installed, or nothing, for them.
Just my $0.02