Slashdot Mirror
File Packaging Formats - What To Do?
Jeve Stobs writes: "It seems that nowadays, there are three ways of distributing a program. In a tarball (be it a .gz or .bz2), in a Debian package, or in a RPM. These are all fine methods of packaging a piece of software, but they each have their places, and they aren't as comprehensive as I would like. I really think that, as we move into a broader user base with the variety we have so far (not to mention the variety we are likely to have in the near future) that a new method of software distribution is needed. osOpinion has an excellent editorial piece which details some solutions to this growing problem."
Soon enough a .zip type standard will gain dominance and such fussiness can end.. lzh, arj, and those other ones from dos days all eventually (should have?) died out and left .zip as the standard.. hell, why dont you linux guys just use that? pkunzip /d source target..
Regardless of its capabilities, Unix is
---
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
Perl 6 will give you the big knob. -- Larry Wall
Why 1500 packages? Just get some packages from the A, AP, D, K and N disks. Slackware
How to contact me - http://www.pervalidus.net/contact.html
What about something like updaterpmdb, like updatedb for the locate command ???
An Education is the Font of All Liberty
You can search for the package that owns a given file with dpkg -S
---
END OF LINE
And why does this remind me of a certain scene in "Dark Star"?
Doolittle: Hello, Bomb? Are you with me?
Bomb #20: Of course.
Doolittle: Are you willing to entertain a few concepts?
Bomb #20: I am always receptive to suggestions.
etc...
The goals of newbie users and the goals of sophisticated power admins are very different. RPM probably is a fine choice for newbies and others who may be more experience but don't care to worry about the administration of what is installed, especially on a home or office desktop.
OTOH, for someone like me that cares about what is installed, how it is installed, where it is installed, and the overall security of my server, I have found that RPM just gets in the way and increases the frustration. I'm personally dealing with details that RPM is supposed to help me avoid dealing with, because I need to deal with them, not avoid them. RPM is definitely NOT easy for everyone.
The correct answer is, there is no one size fits all. Standardizing on a single packaging format is the wrong thing to do, unless we want to standardize on one type of user (which the other user types are not going to be happy about, at all).
now we need to go OSS in diesel cars
I've been thinking about this for a while. The /usr readonly, /var read write, and mount /usr/share over a network. /package// then you loose this.
problem is you have several classes of files:
Binaries - exported over a network readonly. Maybe arch independant.
Data files, read only, or read write, may be on a network, machine local, or per user.
Configuration, again, network, or local, or per user.
The current fs layout is organised like this, so you
can mount
if you have
A ports tree would be ridiculous for Debian.
There's already APT, which is awesome - 'apt-get update; apt-get dist-upgrade' goes and updates your ENTIRE INSTALLED SYSTEM (except for kernel and non-Debian packages).
Installing individual packages is trivial - 'apt-get install PACKAGENAME'. And if you want the source, just do 'apt-get source PACKAGENAME'.
There are a number of frontends for apt, such as Gnome-Apt (not sure whether it's still under development, or orphaned), Aptitude, Console-Apt, StormPkg, and Corel's get_it.
Ah, yes. I've been thinking about this for some time. I would love to see something like this. Nice and clean. Delete that file and you "uninstall" the application. Simple, clean.
Just to toss out some ideas:
Imagine if the entire OS was one file. So you might have a base Linux, BSD, or whatever system that you would install just by copying a file over. This would require some type of very basic system for managing the "filesystem" (or database, whatever it would be).
MVS uses a very flat filesystem model. And you can drill into the datasets as if there was a directory structure (which I guess there is, sorta, from the layout of the dataset). I'm not saying I like the MVS filesystem. It sucks because it's so cryptic, but there is no reason a modern filesystem patterned after it would have to be that way.
In order to do this right I think it would require some major architecture changes to any OS. That would facilitate this one file == one application, system.
Simplicity, I like it.
A source install package manager will also need to properly integrate local hacks/patches to the package. If it doesn't do that, then I won't be able to use it for those source packages I do have my own code hacks to (several of them, such as apache, bind, ssh, qmail). There will also need to be a standardized place for it to find any "local modifications to source" for a given package so it can automatically include them.
now we need to go OSS in diesel cars
You need to read up an Apple's OS X packaging model. It's not nearly as stupid. "extracting the program and installing it for you" is moot because the program and all the things it depends on are self-contained--just download and unpack using your favorite decompression utility, and there you are.
If you care to look at the source, you can look at it--and compiling the source produces the package.
I would not EVER run a system such as you describe.
I have a positive modifier on Troll. When I mod someone Troll their karma should go UP!
from the jar tool :
...jar is a general-purpose archiving and compression tool, based on ZIP and the ZLIB compression format...
You can even use winzip (ug) to crack jars open.
--d
std::disclaimer<std::legalese> sig=new std::disclaimer; sig->dump(); delete sig;
-><-
Grand Reverence Zan Zu, AB, DD, KSC
I am somewhat perplexed. OK, our current package system (I'm using Debian) has its own problem if you install stuff (especially libs) from tarballs. That's clear. But how on the earth could it be solved using self-extracting archives? And why on earth would you want to do a self-extracting archive anyway? It is not secure, you need some installer anyway to remove the packages and it just does not make sense at all.
What we need is an easy way to register manually installed software. Something like stow, but much more powerful. Yeah, that's what we need, not self-executing archives.
Real life is overrated.
It was said before. If your package needs a mail agent be installed, how are you going to make sure it works when I have qmail installed instead of sendmail?
now we need to go OSS in diesel cars
Damn. Sorry about that last post... I forgot a closing tag symbol. I know... use the preview.
:
...jar is a general-purpose archiving and compression tool, based on ZIP and the ZLIB compression format...
from the jar tool documentation
You can even use winzip (ug) to crack jars open.
--d
std::disclaimer<std::legalese> sig=new std::disclaimer; sig->dump(); delete sig;
--
Regardless of its capabilities, Unix is used by many people as a single user workstation, in a role identical to those other OSes. What do you think the target market for Loki's game ports is? Who uses KDE and Gnome?
Obviously, with a multiuser server where a lot of people depend on it, you need a good admin. I am not suggesting that anything be done to take away that admin's ability to get his job done. But for Joe Schmoe who wants to play a 3D game on his home PC, he should certainly be allowed to play the game without having to know where Mesa's libaries go.
---
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
One of the strongest points about Debian, I think, more than any minor technical distinction between .deb and .rpm, is their strong centralized packaging organization that solves the above problems. (Based on this, they can also make nicer tools e.g. for automated network-based updates.)
Now, if only Debian stabilizes their new release so I can install it on my PPC...
If a thing is not diminished by being shared, it is not rightly owned if it is only owned & not shared. S. Augustine
Then don't do the "install everything" install. I use dselect to get exactly what I need. For a server that means less than 70megs installed, for a gnome desktop there is more, but if you take a little time to pick and choose, it is still quite reasonable.
Although I won't discourage you from using tar and compiling source, it's a good skill, but if you've got the time for it, then I say good luck to you. I just don't like admining boxen that I have little idea what is installed, and precious few tools to find out, mainly cd and ls.
The old libaries are often from non-free binary-only progs, that can't be recompiled anyway, no ones got the source or is allowed to re-distribute it, etc.
I don't quite get by what you mean "depend conflicts", unless you're trying to get 2.2 installed in under 50megs, which is a bit hard, because debian wants to install a semi-full system, internationalization support, nurses, a large terminal db, dpkg, plus things like debconf, which is debatable. In that case there is at least 1 debian derrivative meant for the embeded market.
The current Slashdot moderation system is made by gay communists!
Now, let's say that one attribute in the database is the directory, and another is the file. (This is not unlike how MUDs and MUSHes represent their objects.)
When you go into a directory, you see all files for which (object.directory == user.directory).
Now, when objects move around, the database and filesystem remain in sync, as they have become a unified concept.
When used the reverse way, it works just as well. I want to run the XYZ web browser, go grab the nth version found in the database. This is perfect for a GUI interface, where paths should be transparent or non-existant, and where objects just -are-.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Founder's Camp
Founder's Camp
News for non-Nerds. Stuff that matters.
ZZiiiiiiiiiiiiiiip it.
Ziiiiiiiiip it.
Actually, my favorite compression format was
a trash compactor.
It did wonders for my mac.
___
It's the end of my comment as I know it and I feel fine.
That's an MUA, not an MTA. The generic mail interface is the "sendmail" command. MTAs other than sendmail provide their own version of this command, taking most of the same options as sendmail (and possibly ignoring some of them).
Fine, but don't put cocksucker-marketing dorks looking to fill this market in charge of my linux. That will be the death of it. Debian GNU/Linux, in particular is quite fine as it is. Let corel or someone else do the luser-related tweaking, and simplification stuff, just make that a schmeer on top, one that I can always wipe off when it gets in my way. What I want is a real server OS (that is not BSD licensed, sorry no flames meant, its just the truth), that you can make into a desktop, if you want.
The current Slashdot moderation system is made by gay communists!
Agreed. Once the job of the LSB is done and all major distros agree on it, we can proceed with either creating new package manager, or refining the existing ones.
.deb are both great, but both have some serious shortcomings. What we need is a flexible, intelligent package manager that would work with source as well as binary packages (i.e. if you pick up a source package, it compiles it on your machine and then installs it transparently).
.src.rpm and, while it's no biggy for me (you sometimes have to adjust some parameters, make a few changes to the spec file), I understand it can be a daunting task to those who're not used to it.
RPM *and*
I use Red Hat and hence deal with RPM extensively and frankly think it's great.The only problem is that for performance reasons I like to have some things compiled on my machine (e.g. kernel, compiler, httpd...). That involves picking up a
-----
Yeah, like me and all my cool linux friends are totally like laughing at you and what not! ;)
What you need is a recent cheapbytes debian cd and some cool t-shirts, six-pack of jolt + a bottle of voka, then you can join in the fun! Driving around, looking for BSDer's and yelling crap at them, "you call that liscense free!!!" "microsoft could take yer code, and sell it!!" "you smell funny!" "Cut your hair, the early 90's sixties revivial ended last century!!!" etc and then burning tread, peeling away as the cops whip it around with the lights flashing... ah to be linux and young..........
The current Slashdot moderation system is made by gay communists!
The best would be Linus or RMS defines standards, but let's wait for GNU/Linux to maturize a bit more.
99% of Linux's much ballyhooed ability to run for weeks, months, years on end is that users are NOT installing new software or new versions of software every other day.
Every installation is a chance to screw something new up, and because of the potential for interactions among all the softwares installed, the likelihood of problems increases exponentially with each package installed.
What's a sig?
Ha! and RPMs aren't fragile? How many times have you installed an RPM that has broken dependencies? The argument you make here applies equally to RPMs.
-- you too can have an annoying sig!
InstallShield for Linux should be their next work.
How to contact me - http://www.pervalidus.net/contact.html
Installing from source would not really break your system. If you say compiled the latest mozilla source, and did not install it in /usr/local (the ideal place for non-package managed software) THEN you decided to say install a netscape or mozilla deb, then you might have some problems, but then anyone who doesn't realize that should not be installing software, just using it.
.. . .. . it could get pretty thick. O(n^n) or something close...
The hard part about that suggestion is to get the developer to document all of the potential problems in such a ports/autoconf/make system. Most RPMs and debs are made by maintainers, not the original developer, so someone else is cleaning up after the coders. Plus how much data must be maintained? When you multiply the number of packages, by the number of libs, by the number of distro's by the number of hardware platforms, by the kernel versions, by etc etc..
If you think a prog will work without the demanded lib, you can always do a "forced" install, and try it out. Nothing except fear to keep you from giving it a whirl....
The current Slashdot moderation system is made by gay communists!
But rather then trying to figure out how to break this excellent idea so it works with old tools, why not fix the old tools. What we want is the existence of a file to "install" it.
For the shell: modify it (or the exec system call) so you can execute a "package" and run the application. Tell everybody to put ~/bin in their path. And then tell everybody that sticking the package in ~/bin will allow them to run it from the shell.
For things like the Gnome start menu: fix gnome to look for packages in ~/bin and extract the necessary information (help, icon, etc) from it. Then again, putting the package there will suddenly make them appear on the menus.
To "install" a package so all users can see it, become superuser, and move (or link) the package to /System/bin.
To "uninstall" a package, just delete the file (modify rm so it does rm -R on them automatically).
A package that has to change the system somehow (like install a service) will pop up a question box when run saying "do you want to install this". If the user says yes it then runs some kind of "install shell" program. This is a setuid program that asks for the root password in a pop-up window and if the user types in the correct thing it then runs the script. Cheap solution: user must put the "file" (jar/.app/whatever) into ~/bin to see it without installation (and their path must contain ~/bin). Making shells see the command is the same as making the Gnome command see the command or the Windows start menu see the command. Some thing needs to be done other than simply putting the file on the file system.
actually, this information isn't all that hidden. Try doing "man dpkg". You'll see that you can get a list of all packages by typing "dpkg -l" and a list of all files in a package with "dpkg -L ".
This was one of the key reasons I switched from Linux to FreeBSD. After trying to get things working on Debian, Redhat, and SuSE I tried FreeBSD and haven't looked back.
I remember seeing something about a organization to standardize all the Linux file system layouts etc. but nothing seems to have come of it. Redhat was not a part of it and Slackware falt out refused to abide by any decisions that they made.
It seems to me that Debian has it's act most together but has problems because it there are not standards.
Contrast this with a *BSD OS (and perhaps others) which have a centralized system of source and/or binary (ports/package) installation using trusted files. Download, make, grab and install all dependencies, install, done. And everything is mantained by a group of people who make the latest greatest software buildable and runnable on *BDS. This is, of course, precisely because there is little fracturing in the origanizational structure of the overall OS. A weak point is trying to update a program to a newer version (I've seen ways to do this but it's not exactly simple).
It won't happen untilthe Linux *distro leaders* decide to wake up and compromise on this key area of standardization. I know Linux users love to use the 'multiple choices' argument but at some point you have to start catering to the majority rather than the minority... (yeah yeah, sounds more and more like a commercial OS)
Anyways, I don't mean to slam Linux but it's a key area of weakness. It's ironic that a great strong suit of Linux is also a major headache.
Fsck cluebie moderators. I'll say what I want, offtopic or not. And fsck having to qualify every bloody statement just
By opening a socket to port 25, perhaps? Or by providing a /usr/sbin/sendmail that's option-compatible (as, I believe, most of the MTAs do)?
One of the things that annoys me greatly is packages that install stuff into my system configuration. I want total control over my system, including what services are started at boot time, and in what order.
OTOH, I can understand someone else not understanding at all how the system starts up, and wants the package to take care of that (if its a service to be run). Part of the difficulty of all this is that we have not standardized on one kind of user.
now we need to go OSS in diesel cars
Assume I am a user on a system that only has emacs and I really love xemacs. Then I install xemacs using my regular account, "amorsen".
I discover that others need xemacs too, and that they have started using the one I installed. Then I grin evilly and change the xemacs executable to fork() a little X event watching program before it exec()'s the actual xemacs. This way I can gather passwords from unsuspecting users.
Software installation must be done by trusted users, and noone else. Anything else would require an operating system that actually protected users from the programs they run. Such an OS would not be called Unix.
Benny
Finally! A year of moderation! Ready for 2019?
I am reposting this from a previous article because it makes more sense under this one.
Ok, as only partially-initiated, I must ask, in spite of the simplicity of the philosophy of Unix, why oh why are there so many damn interdependencies in applications? Example: I install RedHat (yeah, shut up, it was the only thing that would install over DHCP on this old ThinkPad, after trying FreeBSD, Slackware, NetBSD, and TurboLinux), and choose the most minimal of configurations, and also choosing some small tools like cvs, etc. Well all of a sudden it is prompting me for all sorts of other dependent packages. I could not believe it when it told me I needed the entirety of KDE, and *then* also GNOME to satisfy dependencies! That is bullshit. Tk, Tcl, Python, Perl, Expect (!)...how the hell many things do I need to install? Am I the only one who thinks that backending GUI or administrative applications by Perl is just a god-awful abuse?
Sure this is just one experience, but I've found the same general thing when installing other distributions. Is this just a commercial flaw? Or do other "non-commercial" distributions like Slackware and Debian not require this? I just boggle at the horrendous amount of crap that even the most trivial of applications is dependent upon.
Ok, I'm putting on my asbestos trousers...
It's 10 PM. Do you know if you're un-American?
What I see most important in the short term is the complete lack of a standard installer (the likes of InstallShield) and a standard GUI for it in X and curses.
1. It should be a binary installed on the local system and so separated from the packages it will be installing. (for security reasons as stated elsewhere in this thread)
2. All packages should be digitally signed and this signature has to be validated before installation can commence. (be vary about M$ signatures ;-) Distribution maintainers should include trusted signer's keys in the distribution for convenience.
3. Within the installation GUI it should be possible to get a clear view of what-goes-where in terms of files contained in the package
3.1 For this sort of a major installation system overhaul to become reality there must be very good tools to create these new packages and utilies for converting existing .rpm/.dep/.tgz packages to whatever this new system will be.
4. Also installation paths should be configurable and there should be a button for checking and updating the system path setup if needed -automatically. Also post copying/installation configuration should be available through the same GUI, so that one is able to install and configure software easily through a "wizard" in the beginning and then get down to 'vi' if tweaking is needed at a later time.
5. The installer should have a decent help on LSB directory meanings and a FAQ of known best practices of software installation. (I use /opt for just about everything)
6. The packaging format should be something like the .tgz package format *BSD's ports collection with automake/autoconf Makefiles for dependency checking and a way of automatically fullfilling these dependencies if needed á la the ports collection (It really works wonders - it is something we should adapt from our *BSD kinders)
6.1 The packaging format should also support source compilation i.e. instead of being an "only binary" package the SW could be distributed in source form and the installation system will give the local machine optimisation flags to the Makefiles of the package to be compiled. Flag override should be also available in the package if the SW is known to malfunction with some optimisation flags i.e. it's not SMP safe or breaks with high optimisation parameters.
6.2 There should also be a proper uninstall scripting in the installer and another handy feature would be the possibility of making an orphan check in the installer i.e. when a software is uninstalled no shared libraries should be removed (this semantics will leave orphaned libs hanging arround, but retain other SW operational if it hasn't been registered with the package system as using this library) Now with orphan detection root has direct control over what libs are to be removed as surplus and if something then breaks he will be able to reinstall what ever he just removed, instead of being left guessing what essential part was removed with software package ZYX.
7. A new binary fileformat of the .jar like would be helpfull if one strives to minimize the directory count of the box, but at the same time it compromises control of individual files in a given software (think icons in KDE as part of a kde2.package - how can those be updated easily and conveniently?) Perhaps some kind of a hybrid system with a hierarhy of
/opt/kde2/kde2.package /opt/kde2/conf/(config files) /opt/kde2/icons/(icon files)
say
and
and
8. At the same time we should try to rationalise the current confusing directory hierarchy system of /bin, /sbin, /usr/bin, /usr/sbin, /usr/local/bin, /usr/local/sbin, /usr/share/bin, etc. as this becomes entirely uncontrollable after a while of mixing packages and/or source compilations from various sources on any given system.
Nowadays it is complicated to get a grasp of what's installed on a system just after installation if using something like RH/Mandrake that stick every SW beneath the sun and their friends in a default installation. (even with the minimum/expert installation =(
Hopefully someone with enough programming expertise to actually do something about these suggestions sees this post and finds some of it rational enough to try to implement a system like this on Linux/BSD.
I'm looking forward to see the day it works,
++ Raymond
You write up specs for a "meta-package" format, and EPM will build various packages for you. It supports RPM, .deb, Solaris packages, IRIX packages, and HP-UX packages, as well as a "tarball" format that installs with a setup program (user-supplied, or you can use theirs).
It's GPL, and it's packaged for Debian (for woody, not for potato, unfortunately, although the woody package works on potato).
sub make_package {
my $library = "hello, world";
my $program = sub { print $library,"\n"; }
};
# create the program/package
$package = make_package();
# change the environment incompatibly
$library = "oops, wrong environment";
# run the program
$package->();
This outputs "hello, world" in Perl. In the real world, it will output the wrong thing.
if Linux is to standardise, RPM seems to be one of the most easy to use formats at this point
/* Linus is The One
Why not have some sort of header, like scripts have or use mime-types or something to call the package manager to install the package?
Apart from that, I haven't had any problems with debian packages and half the things that the author of that article wanted aren't neccisary in Debian.
AussiePenguin
Melbourne, Australia
ICQ 19255837
Jeremy
Melbourne, Australia
Jabber Australia
Admittedly this applies only to tar'd source packages, but the autoconf system already allows you to structure your system that way: for a package foo, just configure it with
/usr/local/foo/bin and run
/usr/local/bin/$FILE; done
/etc/ld.so.conf, and if it provides man pages then ditto for /etc/man.config, but it's no great hardship.
./configure --prefix=/usr/local/foo
and then after the "make install" go to
for FILE in *; do ln -s `pwd`/$FILE
If the package provides dynamic libraries they you also need to change
"The question of whether machines can think is no more interesting than [] whether submarines can swim" - Dijkstra
If you ask me, i think RPMS are best for compiled code but tarballs are best for source for source.
-Compenguin
Time and time again we hear the call for standardizing something. The common argument tossed out is that such and such standard is needed if Linux is to succeed. I say baloney! to that. Linux will survive, grow, and prosper, on the basis of what has made it do so, so far: its diversity and opportunity to try things in a different way.
If we are going to standardize something, then maybe what we should standardize on first is a single type of user. Afterall, if we only have one type of user to have to deal with, then we don't have to deal with a diversity of needs and we can focus on exactly what this one type of user does need. Then we can have just one distribution, one filesystem layout, one package format, one window manager. Hell, we might even be able to narrow it down to just running a single application. Then Linux will RULE!.
... in your dreams!
now we need to go OSS in diesel cars
Yes, if bundles are just big executable archive files or directory trees with a known structure, you don't need a database--you can just search through them in a more traditional UNIX shell style. A database approach would be another way, though, of letting both users and packages find the executables they really want (the "owned by..." was just another example--for example, for security reasons, I might not want to execute files owned by anybody else right now).
I already asked RedHat to implement that some time ago - see this Bugzilla entry
slow news day eh?
personally, i don't understand why cardboard boxes have been around for so long. I figure, if you order a washer/dryer combo from a store, the cardboard you purchase it in should be able to unpack the washer/dryer combo for you, set it all up, and do a complimentary load of laundry.
my not-so-serious point is that tarballs and zips are the cardboard boxes of the computer world. They're meant to do one specific task, and they do it well. No one can say the tar command isn't pretty robust. But basically, do you care about the packaging something comes in? I sure as shit don't. I care what's in it. - *nix, generally being more hacker oriented has always had a do it yourself attitude. Personally, i don't want to see a single file that extracts, runs, and does your dishes all at the same time...that's just not what i switched up for.
FluX
After 16 years, MTV has finally completed its deevolution into the shiny things network
"It is seldom that liberty of any kind is lost all at once." -David Hume
Loki Setup is doing much of what people are describing here, although it's not very good yet at dealing with all packaging systems.
;-)
Setup is GPL, features an easy-to-use GTK+ UI, relies on XML files to describe the packages (and also the UI via libglade), generates uninstall scripts, handles RPM files, pre and post install scripts, etc... I also happen to be its co-author
Most Loki products use it in conjunction with Makeself, which is included in setup, and enables programmers to make self-extractible program archives.
Stéphane Peter
Stéphane Peter
Codehost, Inc.
Only because you are doing the installation as root, you don't have to run the application as root...
A new package format that would combine the strengths of the current various is a good idea, but (and it's a big but) I hope the author isn't the guy to do it (he doesn't have a good grasp of security..)
.02...
He mentions making the package self-extracting - "just do a chmod +x on it, and away you go"
Sorry, but that's why "security" in Windows is so abysmal..
Think about it - to install, you're running this file as ROOT - would you run a binary from an unknown source as root? (I don't even untar source as root!) - this is inherently a bad idea.
Just my
Packages are nice, but really, if we want to see Linux make it in the Real World (TM) we need to advance to the 21st century and recognize that we must have a simple and easy means of installing new software. I propose that we follow Apple's lead in this area and move to Self Extracting Executables, ELF binaries that you run and will extract the software and install it for you, without the hassle of remembering arcane flags and what program you're supposed to use.
/opt/local/lib/install/.
Just look at it! The author of the article makes a very good point. How many of you really look over a binary before you install it? Do you just rpm a package and then run it? What do you have to lose from running this random binary? No more than if you downloaded the rpm and ran the binaries contained therein.
What we as the Open Source community need to do is create a standard install tool, like what windows programmers have with the install shield software. The software could be customised, and could be written to reconize the directory structure, and install the files in the correct locations, maybe through the use of certain files that would be kept in a standard location, like
So, whaddya think? Think we can get something whipped together? Even just a proof of concept done in a combination of perl and python? We certainly don't want to make the mistake OS/2 made and not at least keep up with what windows has had for years.
-ssd
GNOME and KDE also have a similar concept.
My Blog. Sela Ward can sell me long distanc
I've always despised the idea of hard-coded paths. What we need is symbolic path references. (Not to be confused with symbolic links, but I don't feel like flipping through my thesaurus.) Instead of putting a file in "/etc" or "/usr/local/etc" (not that packages should be allowed to touch /usr/local). But instead you copy it to, say, "$PKG_DIR_CONFIG" which can be whatever you want. Or better yet, taking a cue from autoconf, "$PKG_PREFIX/$PKG_DIR_CONFIG". And similar variables for binaries, libraries, data, and documentation. Then, not only could a single package be made for almost every distribution, but the installation method can be controlled by the user if the usual install paths aren't desired.
Any sufficiently advanced civilization is indistinguishable from Gods.
That idea's got a lot of merit, but sadly - that's just not the UNIX way. Take the PATH for example. If every application had its own directory or whatever, your PATH variable would be a million lines long. So you'd have to think of a whole new infrastructure for executing apps.
Actually, I've used rpm and deb packages and like both. I heard a rumor, however, that debian wants to use a ports tree much like the *BSD's. I've used FreeBSD before and the scripts made installation and de-installation a breeze. "Make install" to install and "Make deinstall" to remove the packages. Does anyone know if this rumor is true about Debian and the ports tree?
The reason BSD ports works at all is because it's handled by one small group. Since we have X Linux distributions, we would need X small groups. And no doubt each of these small groups would do their ports differently than the others making them all re-incompatible.
Beyond that _very_obvious_ problem, there's also the fact that a large number of (would-be) useful ports are completely broken requiring hand-massaging of the source. Go put yer head back up yer BackSideDoor and we'll call you when it's safe to view the world again.
or just statically compile them, ban the lib!!!! down with /usr/lib. # find / -name "*.so" -exec rm {} \;
/usr/bin and give them one /etc/(progname).conf to config it. Sure, that'll work. That would simplify installing Xfree. We could even call it xfree.exe. And erase all those wacky /dev/ files, just make one file, let me see we could call it sys.config or something similarly wacky, that would list all of the devices and their drivers, cool!!!!
/dev/hda just:
Make the prog, no matter how big, to be just one file, put it in
no more
device:=hdC:/
device:=hdD:/usr/bin
device:=mouse:/bin/gpm
MSDEX:=hdE:/bin/atapi.exe
cool, I think I'm on-to something here, I'll work on it and get back to everyone real soon.
The current Slashdot moderation system is made by gay communists!
Install alien.
> 7.Something like Novell Directory Services
LDAP and the pam_ldap libraries are already headed in that direction.
While ignoring whatever M$ is doing right now (I've given up on following what standard they are mauling today - regardless of what you think of the rest of their work, they have a habit of breaking standards that is inexcusable), LDAP is fast becoming the directory protocol of choice. Currently, one can use LDAP directory services for any Unix utilizing PAM (definately Linux and Solaris, possibly others?), Novell, Apache, Netscape Suitespot/Iplanet, and alledgedly NT 4.0 (with the netscape synch tool - I've never actually found anyone who got this to work, though).
Right now, the worst problem I've seen with LDAP is the lack of a really good administrative interface - managing users, groups, etc., is a real pain with every interface I've had the mispleasure of using.
But it's on it's way.
All operating systems suck. Some just suck less than others. (and some are virtual black holes)
There is no reason for Linux to duplicate DLL hell from Windows.
And everybody asks "what kind of interface is friendly for the user" and talks about installation wizards and other crap. What is "friendly" is when there is a little box in their file browser that is the "program" and they click on it to "run" it and they NEVER have to "install" it.
Static linking will 100% allow this for programs that don't have to mess with system resources like drivers or continuously-running services. For programs that do have to mess with the system, I recommend that the program have compiled into it the ability to execute a setuid utility (that asks the user for the root password) that can run a script to "install" the program.
And he did not mean static linking libc or Xlib or other things that are obviously part of the system, he was talking about static linking those hundreds of Gnome libraries that are making it almost impossible to get Gnome to work!
I almost agree with you. When I first started using ports, I thought they were great. Then I wanted to upgrade GNOME. Oh, wait, there's no way to upgrade ports. So, I got to get a list of each and every package that seemed to have something to do with GNOME and delete them one by one, then go and reinstall the whole thing over again.
.deb's are the best.
And if they go back and do it again, an apt-get like system would be nice. Compiling is great, but for some large software systems (ala KDE/GNOME) it just takes too long to compile the whole thing.
If they can fix those two problems, I'll agree that the ports system is the best out there. Until then, I'd have to say
So why not just keep statically-linked binaries in /boot/bin, /boot/lib, etc.?
Look at the gnu stow package --- It facilitates this.
It would be nice to remove an application you simply blow the directory away. This would sorta make complicated install programs and package managers obsolete.
There is power in simplicity.
Perhaps I don't have my full dosage of clue, but, while the LSB is nice and all, I still would like to see broad standards to which all distributions conform. Linux, the net, and open source software in general is largely based on open specifications, standards, so that things can interoperate. I'd like a few things cleared up:
/usr/local/* ?
/usr/home, /home ?
.*rc)
/usr/*,
/var usage
/opt usage
/users,
init scripts: System V, BSD ?
name and format of configuration files (*.conf, *.rc,
Also I think there should be a unified package manager system. It seems to me package management needs to migrate to a standardized repository or database (dare I say "registry"?) of application information, indicating interdependences, and what is installed. Somebody mentioned OS X-like application package system. I don't think that is entirely feasible, because many packages consist of different components: applications, documentation, system components - these all need to be put in their correct place. We hate the windows registry because it is of some proprietary binary format that you need a tool to use, but what about a simple XML file, or micro-database, where information is stored centrally?
You might even migrate various application configuration files into this, but that's pushing it, and for the most part, application-specific configuration files do the job just fine (I believe there is at least one effort to standardize application configuration files).
Again if things are already being done, then fine, I'm not aware of them. Ideally one should be able to install any distribution, and immediately know where things are and how things work, having used any other distribution, and be able to install, configure and remove packages in a standardized way.
It's 10 PM. Do you know if you're un-American?
Why should you be limited to make files for this reason? Man pages often tell you exactly what files are related to a piece of software, and debian lets you tell exactly what files were installed where by what package. Plus, there's the added benefit of having all this nicely logged without having to go through each directory by hand and cleaning up if you want to delete something. While I'm not trying to bash makefiles, they're not the end all, and the ease provided by a package is usually worthwhile for many people.
"I may not have morals, but I have standards." - Marcin
"I may not have morals, but I have standards."
Sometimes what you say will work, but not all Makefiles have an uninstall option!
Also, you should try to run the program before running "make install" to see if you like it... - a lot of programs run just fine without having been "installed".
--
Ner lbh sebz gur HFN? Gura lbh'ir whfg ivbyngrq gur QZPN!
Maybe you should read past the second paragraph?
I think that the new format should store all of a program and anything else under it's own directory. Just like Microsoft.
I know it sounds a lot like flame bait but it trully does make sense. Currently, you have to search around your file system to figure out where a program installed itself.
I would like to see all programs use the following installation scheme:
GNU Hurd is supposed to be going that direction from what little I have read. Program are stored in a directory structure of their own and then the kernel does a merged view of the structure to make it look like somewhat of a standard Unix filesystem structure.
Anyway, you don't need a separate database. You need an SQL interface to your filesystem (which should support user-defined attributes to be truly useful).
--
RPM ships with scripts that will build large parts of the dependency database for you. Yes, you'll still need to do a little tweaking after the database is built, but after a relatively short period of time tou'll be OK. Hell, I've installed RPM on IRIX and haven't had much problem with dependencies.
-- Minds are like parachutes... they work best when open.
Incompatable in what way? glibc is glibc, xlib is xlib, and sendmail is sendmail no matter what distribution you use. I can't think of any other possibly incompatability other that file-location and possibly library version conflicts, which can be handled by dependancies. It's perfectly possible to install a Redhat package on a Mandrake system, for example. With alien, you could install .debs. :)
So... you're worrying about your installation script is going to do anything nasty, but you're quite happy to implicitly trust whatever program it's installing?
The only possible courses of action are:
* Carefully check the source of the software
you're installing and the installation
procedures
* Only get trusted software from a trusted
source
* Sod it, and hope for the best
If you think 3 main packaging ways are too much, then why do you want to add one more ?
-- javaDragon is an instance of JavaDragon.
whats wrong with a tarball? i cant think of a better format. in a single well compressed file, you get the source (and/or precompiled binaries), no goofy scripts run when you extract it that are likely to destroy some unrelated config file or add some backdoor to your system, while having only a small chance of achieving their intended purpose (unless a backdoor was the idea..), and it doesnt throw the binaries to some backwater area of your filesystem that you've never even seen before. you are left for yourself to inspect the code and compile it, or if you're brave, use precompiled binaries. a file format like rpm where it has binary files in it and it runs a script on extraction is a security flaw just as wide as anything a script kiddie reads on bugtraq. The rpm that you think is installing the latest copy of bitchx so you dont have to worry about compiling it (wimp) has probably been modified to spam irc channels and usenet with your root password and things.
Any program is written and tested in a particular environment (libraries, writable directories, etc.) and makes references to those objects. To function correctly, it should really be shipped with the complete environment it depends on. That's no different from a nested function in Scheme or some other fully lexically scoped programming language (sorry, C/C++ doesn't need to apply).
Of course, requirements on applications are a bit more complicated than functions. When shipping the "closure" of a program over its environment in that way, as an optimization, we may not want to ship every single library with it; many of them may be present in the target execution environment (shipping a secure checksum may be sufficient). Furthermore, for some values in the closure, we may want to allow "substitutions". For example, for some libraries, we may want to allow newer versions to be substituted. And some references, e.g., to a "document directory" are dependent in more complex ways on the environment. Such deviations should probably be identified and declared explicitly as exceptions.
Lexical closures get their power from two properties. First, in modern languages, the "free" references to dependencies in an environment are captured automatically and reliably. Second, once closed over an environment, a function can't go out and start accessing other parts of the environment (at least not without being very explicit about it in most languages).
The alternatives (manual declaration of environmental dependencies, unrestricted access) were tried with programming languages, and they led to unreliable programs, and languages got rid of those approaches pretty quickly. We should probably follow a similar path for packaging applications.
Is everyone stuck in Linux? It seems like nobody has used /usr/ports on a BSD machine lately. Personally, I think it's got what everyone needs, being a package system that's got the features talked about here, and it even builds from source. Now, if I'm seeing this correctly, the reason we _have_ source distributions of things is a) for the customizability of it all , b) to have the source at our disposal to do with as we please. /usr/ports allows one to do just that. Coupled with ease of use ('cd /usr/ports/category/myprogram/' 'make install'), I think we've got a winner. Too bad the linux world doesn't have that... Until then, FreeBSD and OpenBSD get my vote...
c
-- you too can have an annoying sig!
It seems to me that the author simply lacks experience with RPM. RPM in its more recent incarnations has a Prefix option so that you can define relocations from /usr to /usr/local or from /usr/doc to /usr/share/doc or whatever. You simply specify directories that can be relocated without breaking the package.
That solves the problem of different directories for different distributions. If you are not using the same paths as the packager, you can give options to RPM to move the files to where you want them. Obviously it's not perfect because some programs hard code path information, in which case the directory cannot be relocated and should not be specified in a Prefix line.
The author also says that a standard .tar.gz should be used. I totally disagree with this. CPIO is very similar to tar, but has some distinnct advantages over tar. One such advantage is the ability to read filenames to include from stdin. Of course there is the tar -T option, which may be able to take "-" as an argument, or possibly /dev/stdin to read files from input. Another advantage to cpio is that it deals with device special files and pipes/sockets better than cpio. Of course all of these are moot points, RPM is already using cpio, DEBs use tar. Either way it's about the same thing.
Another concern was the dependency problems. Sometimes package maintainers will list other packages on the requires line. This is a really bad thing to do. RPM will automatically find library dependencies, so there is no need to do this. Packagers who do this are creating the problem, not RPM itself. Do note that RedHat has a habit of doing this, so they are somewhat guilty.
One issue I would like to bring up is that RPM works best on a system when EVERYTHING is an RPM and you do not install any shared libraries as source. I am thinking of making a tool that will generate a small .spec file which given a directory where a program has already been built, it will make install to a buildroot and then package the files into an RPM. That would be usefull for keeping track of programs that are constantly changing, such as those you are updating from CVS and recompiling only the necessary parts.
Finally, there is a need for a better version of alien. Right now alien is severly broken in that you must run as root to get good results. Alien should instead read the permissions and any device special information from the source file and use that information when packaging instead of requiring root access.
Perhaps another way to fix the packaging problem is a tool sort of like alien that would conver an RPM from one distro to an RPM of another. Something that could relocate files, fix dependency info, and then create an output RPM with the changed information. Of course I still say if the package is made right in the first place, this is unnecessary
Well, that's a lot to think about, hopefully I got some other people thinking too.
-Dave
And I mean this not just in regard to installers and packages, but everything.
And no, I'm not proposing that what we need to do is make Linux look more like Windows or the MacOS.
But there are problems that others have solved and we can draw on their solutions, even if we can't use their source code.
(Even when I was working at Apple I would tell people about stuff from SunOS or Linux that I thought would go good in the Mac - they wouldn't hear of it).
I think an indicator of the problem we face in trying to bring Linux to the desktop was when I was corresponding with RMS about things I thought would be helpful to the users and I suggested an installer. He replied "What's an installer?"
The best installer I've ever come across on any platform, both to create packages with and for the user to install products with is Mindvision Vise.
It would be worthwhile to find a friend with a Mac and download it, and make a little toy installer that installs SimpleText and a readme file to try it out (you can download it for free - the installers created with it complain that you've lifted it until you get a valid serial number. It is possible to get a serial for free for installers for freeware).
It beats the living hell out of anything I've seen for Linux.
BTW - if you want to see an installer that really blows, check out PackageBuilder/Software Valet for the BeOS. The thing drove me to distraction. It wasn't just the way it would corrupt the data in my archives or crash while users were installing my software with it.
What really drove me nuts is that it had no concept of updating an installer when I had built new software to go in it.
With vise you just drop your new files in the folder next to your installer project and tell it to update. It gives you a list of files that have changed and you can approve or disapprove of updating them (or deleting the ones that are now missing).
PackageBuilder requires you to delete the old file from the installer project, which loses its settings, then you have to go and add your file back in and reset your settings. This is probably the number one reason for every time I've been reluctant to release a new version of my software on the BeOS - I enjoy programming it but I hate the damn installer.
-- Could you use my software consulting serv
traceroute and ping are both in /sbin
I don't think they are necessary to boot.
*sigh*
Why do Unix users have to be Sysadmins, but Windoze and Mac users don't? Why are the rules different?
It doesn't look that way to me. It looks like they just want a system that works well. Lowering the sites to Windows would be pretty unambitious.
Obviously it would be nice for the user to be more clued up. But there are a lot of people who use computers these days, and making cluefulness a requirement just isn't realistic. If it continues to be a requirement for Unix, then then people who don't want to learn sysadmin stuff are just going to have to scratch Unix off their list of options. Do you want them to do that? If so, why?
---
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
The LSB should take care of most of these problems. Once everything is in a standard location across distributions, installation methods will be able ot become compatable across distros.
-- Minds are like parachutes... they work best when open.
I'm wondering if all the people posting all the merits of the redhat package manager have ever had any experience with debs.
A lot of the flexibility that the author wants i.e., all the power of a configure script, can be easily acheived by the package maintainer
simply setting up the preinst script for a debian package. I've never seen a system SO flexible. Debian packages have the ability
to suggest, reccomend, and require each other. They know exactly what each other provide, and they describe dependencies in much
more intellegent manner than RPM does. Dselect allows you to easily(if you know what you're doing) resolve package conflicts
and work out exactly how you want everthing installed. Apt will actually fetch and install all packages necessary to install the requested
program(with your permission of course).
The author admits that he hasn't ever used Debian packages, so why bring them into the article?! He talks about how he would like a ;-). One of the main
package manager that will recognize files for what they are and not based on the packages that they belong to(i.e., libraries),
but personally, I don't see the need for this type of functionality when your distro already has packages for virtually everything you
can imagine. Sure, many people would like to install the latest bleeding edge libs, but that's what Woody is for
purposes of packages is to allow for easy upgrades between releases. If you're going to be installing lots of libs from tarballs, it kind
of defeats the purpose of using packages since you can no longer apt-get dist-upgrade and have everything brought up to date. If there's
some obscure library/program out there that there isn't a package for then great, why not become a package maintainer and fill the gap?
It seems like the author of this article knows rpm pretty well, but he shouldn't reference things that he doesn't have experience with...
This is not flamebait!
A musician without the RIAA, is like a fish without a bicycle.
The main debian apt repository has basically the same functionality. With debian, all you would have to do to install vim would be "apt-get install vim". As long as you have your sources.list file setup properly, Apt would contact the main apt repository, download the appropriate package and install it. It really is a breeze.
A musician without the RIAA, is like a fish without a bicycle.
My question, therefore, is why we need Debian packages or RPMs. It seems to me that Slackware has managed to create an easy-to-use system that uses only tgz files, a system that all other distros could rather easily import.
A simple question. Now which directory is ping and/or traceroute in, why is it in that directory? And what isn't that directory in my path when I initally install RedHat?
Rhetorical questions. I know the where but not the why.
Instead of having large numbers of disparate databases, all holding essentially the same information, most of which is never kept in sync with the filesystem (and therefore becomes stale very easily), I'd like to propose that Linux filesystems become package managers in their own right.
And not just package managers. Most of the information that such tools as 'configure' generate is already known -to- the filesystem, albeit in a form that's not readily accessible (hence the need =FOR= 'configure'). But if the filesystem keeps an actual database of all installed packages and files (along with where they currently reside), then 'configure' scripts would become largely simple database searches, which would have increased speed and increased reliability. (No more having to tell 'configure' where non-standard installations are. It'll still find them.)
Also, finding files would be quicker. A linear search is horribly slow, when all you really need is a sorted index that you can do an n-ary search on.
Does this sound a bit like Windoze? Nope! NTFS and FAT32 keep very primitive caches, I believe, but not a comprehensive database. That's why you need installers with Windoze. The filesystem itself is not capable of acting as an "installer" in it's own right. The system I'm proposing would. A simple copy would be as "uninstallable" as an RPM, DEB or SRP. A tarball would have equal functionality as any package manager.
In a day & age where computers can perform feats so astonishing that nobody, even 10 years ago, could have imagined them, and where integration & interoperability have long been established, we are STILL using totally incompatiable methods of doing identical operations on identical spaces. This is stupid.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Try this:
after compiling, issue the following command:
rm -f `find . | grep -v Makefile`
(make sure you use the correct quotes!)
this will delete everything in the current directory and all subdirectories except for the Makefiles. Now you can just tar the directory up and archive it in an uninstall directory or something...
-Chris Andreasen
-Chris Andreasen
Ugh, that's exactly the kind of shit I went through this weekend with Mesa. I hate Linix sooo much right now...
RPMs just don't work. I'm having to do everything myself starting with source tarballs. And when I'm done, the RPM database isn't going to know it. God help me if I ever install anything that uses Mesa and checks the RPM database to find out if I have it or not.
---
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
Some of these problems could be solved by having alot more default groups as well as a more capabilities based security model, instead of the "root uber alles" security model. Different subsystems should have different group ownerships and you should be able to pick who has control of what subsystems at install time. Also a sane sudo config at install time would be a plus. That would allow Joe User to change resolv.conf and Jane User the hosts file but not destroy the sendmail settings or install a trojan accidently. It think we could use finer grained access controls than root and user.
I like the idea of installing more stuff in the individual's home directory, but that won't work right if you do have multiple people using a household computer.
I do see some problem with having per-user system settings, in that it could be a big pain for a neophyte to troubleshoot. It would seem to add unnecessary complexity.
-- Remember: Wherever you go, there you are!
su's to an user with no rights at all, unpackages all files to
This option also includes:
Pgp,MD5, etc, etc support
Name, Adress, Telephone number to the creator of the file.
List of all files, including CHANGELOG
"Yes I understand this may be bad!"*
Launches as soon as the user lists (ls) the file in the directory.
This also includes:
A nice picture with some companly logo
Installation of every packet availible
Some banners to click on while installing
If anyone is offended, my apology, but we all have different opinions.
*(Message which occurs you're customising debian, IE deinstalling Libc6)
//stalle
Dude. Do you really want to have 50 copies of libc hanging around? Or what if each (Windoze) program came with its own copy of directx?
There's a reason for dynamic linking. It's because some of these libraries are huge! System libraries that many applications are based upon should always be dynamically linked. Not everyone has an 80-gig hard drive, you know.
--
Friends don't let friends misuse the subjunctive.
"It seems that nowadays, there are three ways of distributing a program. In a tarball (be it a .gz or .bz2), in a Debian package, or in a RPM.
:-/
What about zip files or even rar files? Oooh, its someone blindly mumbling about linux again i'll bet
(note to the less bright moderators; this is not a troll or flame - just an observation)
--
If Google really cared they would fix Android Chrome to reflow text, instead of discriminating
Applications and tasks have changed over the years, maybe we should work on how to make the fs layout accomodate that.
/bin, /usr/bin, /usr/lib, etc. isn't really needed any more.
Hear hear. Applicatons are more self-contained than they used to be, and a global hierarchy like
What about something like this:
/ - Root
/bin - SYMLINKS to individual user-executable
binaries.
/include - SYMLINKS to include files elsewhere
/lib - SYMLINKS to dynamic run-time libraries
/devel - Development
/devel/include - SYMLINKS to include files
/devel/lib - Static and import libraries
/dev - Devices, same as today (or with devfs)
/doc - SYMLINKS to application-provided documentation
/doc/man
/doc/info
etc.
/prog - Contains program packages
/prog/XEmacs (For example)
/prog/XEmacs/config - System configuration files
/prog/XEmacs/doc - Program documentation
/prog/XEmacs/etc. etc. etc.
/home/user/ - Mirrors above heirarchy,
overriding anything in
the global with anything
in the user's
I know most of you have seen an install shield program. I also know most of you see that custom button and go right for it everytime. What you all need to remember though is that most users are AFRAID of that button. So while the custom button seems awfully limiting to us it's dangerous to them. Another thing that needs to be realized is that the MAJORITY of people who will use an instalation program will be HOME users. All those people in cubicles arn't installing tons of programs. A few IS people are doing that on a massive scale for them. All that said and done I think most people who don't want these installshield type programs are happy with whats out there or what it will evolve too. The windows users though just won't accept anything less than an installshield type program where they click it and hit next next next finish and they're done. I see a lot of people getting annoyed at this but theres really no reason to get annoyed. That next next next finish is just an interface. Windows uers don't care whats going on behind the scenes. So the question really is how do we make this next next next finish interface secure. I know enough to know I don't know enough to answer that question but I've seen some isntall programs out there that are trying to do this already maybe we should throw support to them in helping to make those systems secure. Jartan
But, yes, fundamentally I agree: doing packaging "right" (in my sense) requires breaking significantly with the way things are done in Linux/UNIX right now. On the other hand, it may be possible to get there without breaking existing functionality. Plan 9 actually has most of the necessary bits and pieces, and it has a usable POSIX system side-by-side with its advanced naming facilities.
For example, one way of getting there might be to start by adopting some kind of "bundle" format for GUI applications (together with a small modification to the kernel to make them executable) and to add an enhanced version of "chroot" (with more control over the environment). I think both of those would be natural, the first for better usability, the second for better security in some applications. Over time, other pieces could fall into place.
All communication protocols nowadays talk to each other before starting any kind of transfer. Dialing in with your modem also requires a negotiation about rates, noise, et cetera.
/usr/lib
So, why are packages communicating in one way before installing? I mean, tarball installs poke around on your system. RPMs and Debs use a predefined database-like structure to poke around, anything outside these structures can not be found.
A bit simplified, but I think you will get the point.
System: So, and you are?
Package: foo
System: A foo version has been found, 87229. What version are you?
Package: 239
System: I don't understand the version scheme. Could you explain?
Package: The lower the number, the higher the version.
System: OK. Is an upgrade from 87229 to 239 seamless?
Package: No, some changes in the configuration files are needed
System: Do you supply an algorithm to cleanly change an older configuration file?
Package: Yes.
System: Do you require other software to be installed?
Package: Yes, I need library glibc 2.0 and libfoo 8
System: Well, we have glibc 2.1.3 installed. Hang on, I will make a connection between you and glibc to sort things out.
Package: Glibc issues are sorted out.
System: Libfoo is not present on this system. Any hints?
Package: Yes, it can be on a FOO CD or downloaded from http://.....
System: Libfoo installed.
System: The library path is:
Etc., etc...
And that would help _how_ exactly? This is about installation, not about compression.
Sure, I've downloaded something called 'ClanLib' or libMesa3D and I mean sources. Compiled them libs, installed them, and the rpm which required those libs still couldn't recognize their presence. I know I have to add some stuff to the rpm database, but I've been too lazy to figure that out, many (smaller) OS-projects aren't worth the effort.
Bizar technology?
What you /could/ do though, is put each application in its own directory, and use symlinks to put the right files in the right places...
This also provides a natural way of allowing for chrooting anything that can work effectively when chrooted.
Exactly, the format of the package is totally irrelvant. The main things users need are icons, not enough packages create icons for themselves on the KDE/Gnome menus and this is the fault of the package creator.
.deb because I've had much better luck with them than I ever had with RPMs, and apt-get rocks.
I do prefer
We don't need a better package format we need better packages.
--
It seems to me that if we change the directory structure that more closely represents an ideal packaging system, it might make it easier to implement a packaging service, and it might make everything easier in general.
/bin/[appname]/ - binaries for apps
/data/[appname]/ - static data for apps
/config/[appname]/ - config data for apps
/lib/[libname](/) - compiled libraries, either in one big dir, or with separate dirs
/include/[libname](/) - headers for libs, similar to above
/src/[lib/appname]/ - source for libs and apps
/users/[username]/ - user directories
/boot/[kernelImage] - put kernel images here
/boot/modules/[moduleName] - put modules here
/mnt - same as always
/dev - system devices
/tmp - you always need one of these
/proc - honestly, I have no idea what this does, but it should probobly be there
/var directory I think is pretty much replaced by /tmp, maybe not though)
/.'ers, but from what I've learned about linux, it seems to make sense.
I was thinking something like this:
(the
And I know daemons fit in here somewhere, I'm just not sure where.
Now, obviously this is quite an uninfomed suggestion, seeing as I am quite an inexperiencd linux user, compared to other
However, it does destroy most established standards in the process, but you need change to make progress.
-- Guns don't kill people, bullets kill people. Guns just make bullets go really, really fast.
That's the big problem with RPM, it can do almost everything that Deb can but there isn't the ironfisted standards that Debian has for its packages. Therefore dependancies break when you try to install packages from one RPM based distro to annother RPM based distro. For example one distro might have "Provides: MTA" and annother could have "Provides: email-server" for the same package, or one might install in /opt on one distro and /usr/local on annother.
-- Remember: Wherever you go, there you are!
Oh, I forgot, also Debian packages generally have much nicer pre and post-install scripts. You can do that very easily with RPM as well but in my experience that breaks many RPM frontends that don't watch STDIN/STDOUT for RPM's requiring input and just break. Packages really should ask you for the defaults you want your system to have if it can't easilly pick sane defaults by itself.
-- Remember: Wherever you go, there you are!
Is it configurable? My IRIX box has no quotas (it's my personal box) and I can give away files. Can it be stopped?
--
Stuck in Linux? You obviously haven't used Debian.
.deb has a matching source tarball if you want it.
Debian's apt+deb can do pretty much everything ports can do, and vice-versa. Automatic download, install, upgrades, etc. Each
When you're done revelling in your superiority maybe we could actually address the problems still present in things like ports and apt/deb. Then again nobody seems to be addressing that anyway.
This just goes to show the single mindedness of MS! Who says that all software is produced by a company, and that two companies cannot share libraries and resources.
:) as that seems to be the way MS seems to be going
For me I always install to C:\Program Files\Appname as I distinguish programs by name and not by company.
And as a side note when are they going to change it to C:\My Program Files
C:\My Documents
C:\My Download Files
C:\My Games
C:\My Music
C:\My Program Files
C:\MY Windows
C:\MY Temporary Files
together with My Network (or whatever it is for ME and 2k)
- when building architects are incompetent, buildings fall down! -
I`ve always been longing for a sort of VFS extention for Tarballs or a similar package format. You could put the packages into a special directory without unpacking, and the files are automatically symlinked to the proper directories.
/etc, and the system would take care of the links when you move the package file.
/home/username/packages, the files are automatically linked to home/username/bin, ~/etc and so on. Put it in /packages, links go in /bin, /etc, /lib and any user can use them (given the proper perms).
This way you could edit config files within the package by editing the symlink in
There would be a tool you could run over the package file to give you information about what was linked where, and you could delete the whole package with a single rm .
Of course, dependencies would still be a problem. But this system would cure the filesystem mess. And it would be easy to use: put the package in
What do you think, does this sound feasible?
Actually, on non braindead systems this is not the case. Most UNIX systems do not allow you to give away files. If you can give away files to root and other users, you can easily defeat the quota systems. You can also create some subtle attacks on various things like global .forward directories.
--
Mike Mangino
Sr. Software Engineer, SubmitOrder.com
Mike Mangino
mmangino@acm.org
Apart from the fact that ACE is hideously slow to unpack, all three fileformats only unpack. So whats the advantage of using ZIP over tarballs? I mean there are lots of GUI frontends to tar already...
I have two comments here:
:-)
1) Please give me at least the option of a source tarball. I can't believe the number of times I've wanted to get at the source (on, for example, someone elses w9x box) and couldn't look at it because it was rpm'd or deb'd or worse
2) One of the things I like about Unix in general is the way you can install stuff as you, without touching the system directories, and it'll all work, and then when you've finished you can uninstall using the 'rm -rf' utility:-). I'd like to keep doing this, but all too often nowadays I see rpm'd packages spraying shared libs and include files and who knows what else all over my filesystem. If I wanted a shared lib I'd have asked for it. It's perfectly possible for a package to install a shared lib in the same dir as the executable (which may well be in my home dir) and still run fine. I think packagers need to bear this in mind a bit more...
-- Neil Milne
Right, I'm supposed to intimately know where all seventy-thousand odd files in 560 packages live?
Yeah. Linzip fer crissake. I've been waiting soooo long. Maybe it's time the distros discussed 'standards'. I don't think that standard is synonomous with slavery... the end of freedom... loss of the right to innovate and all that other gatesian bullshit. There's a group that controls the kernel and a good thing too. Maybe we need some kind of committee to kinda keep these distros running down the same track. Or maybe there's a way to do it without another bloody committee. Linzip. I'm waiting.
tar -xvzf someapp.tar.gz ./INSTALL
less
See?
--
Pokéthulhu
Gotta catch you all!
The major advantage that RPM has over tar/make is the ease of removal.
Call me a wuss, but I like to know that I'm not going to have to spend an hour tracking down file all over the disk when something I installed sucks and I want rid of it.
Ugh. Packages. Hell.
Like some other poste mentioned, ideally packages/programs should be self contained - check out MacOSX's solution for things like shared libraries and the like (I think there's an Arstechnica article about it that is pretty good)
But I'm afraid _that_ will never happen...
The second best thing would be a system that:
- has list of dependencies (like virtual packages in debian) for every distro, with the corresponding packages for that distro.
- describes the distro fs differences in a flexible way (do i dare mention xml?) - the Redhat, Suse, Debian, whacked-out-beyond-recognition structure...
if we go even more crazy:
- that includes the source, a standard way of making it, and repackaging it immediately to the native package format of your choice (distro)
- that can include source patches, that can be optionally applied (by user choice/distro description whatever)
- (really crazy) can even (if the appropriate build tools are installed, and the source supports it of course) automatically build packages for other platforms (MacOS, BeOS, Win32)
Can you imagine, one day saying "and now something completely different...",- and just making a new "distro description", downloading a bunch of next-gen source packages, and just rebuilding a fresh new distro overnight -> blammo
It would definately make the lives easier for the poor slobs that have to maintain binary packages for different platforms/distros.
I'm positive i'm oversimplifying things, but universal source packages would be VERY helpful, esp for the open source community. Universal binary packages would be a good start too though.
What _isn't_ gonna happen is that distros converge to a specific package manager... But we could try to put a layer in between.
Oh well... in the meantime i'll just pretend my good ole debian setup is the only distro... They're actually doing good stuff, with apt and debconf, and a bunch of tools to make it easier for debian-maintainers. Too bad it's of little use with respect to interoperability with other distributions.
Anyone can create a deb package, it doesnt have to be a part of debian.
Commercial organisations could create debs of there software if they chose.
One more step, . . /apps/mpg123-0.59.r /apps/mpg123 -> mpg123-0.59.r
or
.
. /bins/mpg123-0.59.r /apps/mpg123 -> /bins/mpg123-0.59.r
The vast majority of RPM packages don't have any valid reason for being installed as root. The main reason you have to have root right now is to be able to write the RPM database. Fix that. For example, give me a local branch of the RPM database and give root the ability to merge that with the main, shared RPM database.
Miscellaneous other reasons for needing to install as root:
- Making the package available system-wide. Why can't I install a package in my home directory, then ask via a root-privileged command to link it from
/usr/bin? Or, more permanently, to move it there. Such a privileged command would still require security checks of course, but these checks can be very well-defined, and it would be easy to ensure that no suid programs were being installed. With a little more work, it could satisfy itself that no common user commands were being overridden (a technique favored by script-kiddies for hiding their root-kits).
- Installing device drivers. Solution: user-space device drivers. We're some distance away from being able to do that just now. For now, elevate privilege to root just long enough to install the device driver, and require root's password to install such a package.
- Installing daemons and privileged programs. Obviously, only root should be installing them. In many cases a daemon doesn't really need root privilege, and in that case it should run in user space and be installable by a normal user for their own use, or be shareable by the mechanism mentioned above.
- Changing system config files. The author should try to write the program so it does this only as a last resort. We should have a way of overriding certain system config files locally, for example, resolv.conf, so that we have a per-user view of the system configuration. As a last resort, the installer can invoke a root-privileged utility just to change the config files, and require root's password.
- (Other reasons, please enumerate.)
This is all by way of saying that we can have mindless (read: stressless; user-friendly) auto-installing packages just like Windows, without breaking security.--
When all you have is a hammer, every problem starts to look like a thumb.
I don't think it's quite so much an issue with the existing package formats as it is an issue with most of the Linux developers out there not really knowing what they want to do. It seems to me Linux is in this phase where a few leaders have been established, they're going their own way, and are becoming increasingly divergent.
It's basically a standards issue. I've used Slackware for a long time.. like it. Tar and gzip is all I need to install a package. But once stuff started creeping in that only came out in rpm.. I was forced to coax RPM work on my Slackware installation, or go RedHat. Maybe that's great for the l33t Linux hackers out there, as it gives them options, but for someone who's more concerned with getting software running on their machine, it's a hassle.
IMO, someone the entire Linux community trusts needs to answer some of these questions:
"Where do we install stuff?"
"What format should the distributed files be in?"
"How do we handle upgrades or patches to our software?"
Every answer to these questsions are subjective. This is why Debian and RedHat differ. I think that someone just needs to tell us how it's going to be, and let us start doing it. If it doesn't happen, in a few years, one really WILL be able to safely refer to Linux as "RedHat" or "Debian."
And I know some people out there are trying to answer these questions. But are they making ANY impact, whatsoever? The only reason the linux directory structure isn't complete spaghetti is because people kind of do what most other people are doing. That works great today.. but I think it's going to implode on us sometime in the future.
Now maybe good 'ol Torvalds doesn't want to take a dictatorship stance like that. I can understand that. But these questions of "standardized distribution schemes" will continue to rise as long as no one in authority stands up and makes a decision. Linux may truly only be the kernel.. but that's not how the world is viewing it.
I guess I'm okay with the issue remaining unsolved, but if that's going to be the case.. I think the community needs to start spreading that news. "No package standard is forthcoming, choose your favorite, live with it, and stop asking for something unified."
But of course, there's additional problems that appear with a statement like that..
- Try "tar -t" to see where stuff is going.
- Use "rpm -ivv" to see where all your files get dumped
- Be prepared to use "--force" and "--nodeps"
Heck, you can't butcher up your linux system so badly that it can't wait until your next reinstall when your Distro-of-Choice comes out with their next upgrade.I want to delete my account but Slashdot doesn't allow it.
You can use lintian to check all the package are installed correctly, and isolate "foreign" files that dont belong to an installed package..
Isn't that what the --prefix, --exec-prefix, etc
arguments to configure do?
I thing tar balls with their configure and make scripts are the best method for installing unless you are on a RedHat system (I use Slackware most of the time) The only problem is that most tar balls don't really have anything in them to remove the packages again if the install went wrong or the software simply is not needed anymore. You have to go in and clean up everything manually. One Unix which has a very nice package management system is AIX which would be useful to have under linux.
I disagree with this editorial. The rpm approach is the right one. rpm attaches a symbolic name to a particular capability to avoid every other package in the universe re-inventing the wheel (i.e. having to figure out whether that package exists).
So for example, rpm is supposed to tell you for sure if you have glibc version x, without you having to write some stupid complicated package script to go and figure out if glibc version x is hiding around somewhere.
Now if there is some issue with compatibility between suse and redhat, obviously something should be done. Ensuring compatibility between different distros in this area was never going to be an easy one, but throwing the baby out with the bathwater is not the right thing.
It sounds like standardised package names is the answer, although that is never going to be a 100% full solution. (If it was, then that would mean all distros are exactly the same, so why have more than one distro? (why indeed?)). But having thousands of packages out there trying to figure all these things out themselves isn't going to help either.
All those 'outsiders' who claim that Linux comes in too many varieties will use the fact that linux software comes in different packages as 'evidence' that Linux is splitting the way the old 'nix did.
What would be really cool would be a package format that was both compressed, but also capable of installing itself in the 'right place' on any distro.
Even RPM confuses me. I see separate Mandrake, SuSE and RedHat packages being distributed for some software.
insignificant sig
There is an alarming lack of education about what parts of the linux file system are for. I'm sure regulars at #linux can attest to the massive volumes of new users asking questions such as "what's /proc?" or "should I install (app) into /usr, /usr/local, or /usr/local/mysql ?".
It would also appear that many application authors don't know where their apps should live. For example, mysql by default (in the INSTALL) wants to go to /usr/local/mysql, but other applications want to sit in the /usr/local/[bin/etc/lib] heirachy.
We need to get someone to provide a definitive explanation of what each part of the file system is for, and how they should be used, so that we'll be able to say "RTFM", and have a sounder understanding of our own operating system.
nf
That's worth thinking about. The MacOS has had something like this for years; programs are registered in a database when an executable is placed in a folder. Programs are found based on what they are, rather than where they are. Configuration files go in a standard place (the Preferences folder) and, by convention, can be deleted without major trauma. This simplifies the usual case for installation enormously.
So suppose we have a filesystem that holds "packages", rather than files. A "package" is a directory tree, and is normally installed intact and unmodified. Where the package is isn't relevant; there's a database of packages and information about them maintained by the file system. This database replaces "PATH"-type variables; everything that looks at at "PATH" type variable needs to become a query to this database.
Unlike the Windows registry, the package database needs to be locked to the file system. It's a cache for finding stuff, not something you edit. There should be something you can put in a package which causes a cache of (package-name package-version attribute value) items to be updated.
You also need a place to store preferences-type data. This should not be mixed in with the installed data; for one thing, much preferences-type data needs to be per-user. This looks like a database of (user-id package-name package-version attribute value)
It's too advanced an idea for Linux, though. The UNIX world is too heavily tied to explicit pathnames. BeOS, maybe.
Don't compress it
We all know that rar'ed ace'ed zip'ed files are the way to go ... hurrah for nested compression! :)
Ukab the Great wrote:
"Dynamic linking simply does not fit in with a healthy model of average joe, consumer desktop computing."
One major problem with this is libraries which depend on hardware in order to function. The first such library that comes to mind is OpenGL. I have used two separate implementations of this library, the pure software Mesa, and a GL implementation from 3dfx for my Voodoo3. As a developer, how do I know which one to use? What you are suggesting implies linking against all possibile versions of a library, dramatically increasing the number of distributions. Also, this is not exactly feasable, as some implementations of GL have yet to be written.
IMHO better management of shared object libraries makes much more sense than the automatic static linking of everything.
--d
std::disclaimer<std::legalese> sig=new std::disclaimer; sig->dump(); delete sig;
There was a programming contest awhile back to make the best package installer, and it was entirely Python based.
I'm at work and can't spare to lookup the link.
Before I part with'em: two pennies weigh ~4.996+/-0.014g, have a zinc core, and the face of Lincoln. You can keep 'em.
Red Hat et al. are not going to give up RPM. Debian is not going to give up deb packaging. I don't see any chance that we will have a standard package format anytime soon. I think we need a meta-package format that encodes all the information needed to create an RPM, deb or other package. The meta-package format would need to store distribution specific information, but at least it would all be stored in one place. Once you have a meta-package, you could then run "metapac --distribution redhat --version 6.2 my-meta-package" and it would spit out an RPM for Red Hat 6.2; "metapac --distribution debian --version x.x my-meta-package" would generate a deb. You could have a utility that extracts information from existing rpms and debs and places it in the meta-package, e.g., "metapac --update-from my-package.rpm my-meta-package" and so on. Then create a centralized repository for meta-packages.
While I'm partial to compiling from source myself, there are some security concerns I could imagine with configuration and compilation scripts that are "overly intelligent." It would be hard to verify at a glance that they actually do what they are supposed to and don't in fact end up setting up a major back-door into your system. (It is a fundamental fact that very powerful systems always have the potential to generate inscrutable behaviour...)
;-) It should. But a little more care probably needs to be built into the system to prevent any source configuring scripts to write to the system at large.
A simple "put files X,Y,Z in locations A,B,C" packaging system is easier to verify as secure at a glance.
Perhaps this signals the need for an intermediate system. One which only has read-only access at first and proceeds to intelligently build a package of the simple type. Users can then verify that it doesn't do anything funny, and then let it place the files in their final locations. Does this sound a lot like a SRC RPM to you?
I know, users should be smart enough to run this phase as a non-priveleged user, but I'm suggesting that this should be the default behaviour of the package management software and it should require explicit arguments to run configuration scripts as root.
This story shouldn't be labeled under "Programming", this is a definately a "Linux" story! Why on earth would anyone else but a linsux user be interested which packager is better, debian's or redhat's?
No, I'm not trolling. This is a fact.
I've only used Debian indirectly, it's never run on any of my personal boxes (because I'm too lazy), but I really appreciated the idea of having dependancies based on roles, rather than a particular version of a particular program. For example, you can specify that your software "requires a mail transport agent", rather than specifying "requires sendmail".
Debian also got a lot of things right by specifying up-front a standard for package naming. I'm sick of all of my dependancies breaking because I dared to install a non-RedHat RPM.
--
The more I learn about the Internet, the more amazed I am that it works at all.
What do we want in a package format?
But how do you do this? It's easy if you leverage the power of...symbolic links.
First, you extract the package into, say, /opt/packagename-packageversion. Under that directory, there's a /bin, a /usr, a /lib, a /whatever, etc. You can even run it and test it
from there, without privileges, before moving on.
Next, when you're sure it was extracted correctly, and it's passed some basic functionality checks, you create symbolic links from within, e.g., /usr/bin/ to within /opt/packagename-packageversion/usr/bin, then chown to the user the package needs to be.
Note that most of these steps can be done without root privileges. You extract it as user "tool", who has basically the rights of a guest account. The function checks are done that way, too. Only once you're satisfied do you need root to set the symbolic links and do the chown to whatever user the files need to be.
You can easily figure out what belongs to what package. Just do a "find" for symbolic links that link into that directory under /opt.
Completely and safely removing a package is easy too, just have that find command remove the symlinks too, then remove the directory.
Because the package's files are concentrated in one place, it's possible to have multiple versions installed on the same system without overwriting each other. The symlinks get a bit more complicated, but you can have, e.g., a Netscape-4.05 and a Netscape-4.07, and pick which one works best for which pages, just as an example.
It seems to me that the existing pakage systems were too inspired by Windows, scattering files willy-nilly. I've been told that in the 70's and 80's software was typically installed the encap way, though not always so automatically.
PHEM - party like it's 1997-2003!
More people (including me) are using jar files to distribute java programs. Maybe peaple can use it for other programming languages as well.
"jar" has the advantage of being on every platform with a java platform. It can be loaded from a webbrowser, it has built in compression, digitally signed signature, and being "like tar", which makes it really easy to use.
If the app is java bytecode, then there isn't really a need to "install" the app, just run it directly from the jar.
But the disadvantage is that jar (and java) is somewhat slow, but as cpu/ram grows, I think it is a good way to distribute software in the future.
I think software installation should follow 2 forks. Obviously we could never replace the option of compiling software by hand, so .tar.gz is here to stay.
And for the other group who just want to click & install, I think the rpm is still the way to go. Maybe we could have an addition to the rpm system where Distro developers can insert their idiosyncracies (is that how you spell it?) - eg a mapping of their file locations ==> all the other Distro's file locations. But why can't they all just decide on a standard and stick to it anyway? Is it to attempt to create compatibility issues so that one has to be compliant with xxx to sell?
Dan
Now, this might get moderated down as flamebait or as troll, but I have to say this: I don't think you guys should be allowed to run a *nix of any description if you are going to start installing stuff left, right and centre without knowing what files are going where. You're all going to think I'm crazy, but I really think the 5 or 10 minutes or so it takes to read and understand what happens when you type 'make install' is worth it. This is not Windows. You are trying to make Linux aspire to be Windows. This is not a Good Thing. It's not that you should make the interface neccessarily easier, but that you should attempt to make the user more clued up. I'd much rather see comprehensive documentation on the lines of "Makefiles for Dummies" being shipped about for the newbies than some new package format being created.
:-)
But seriously, to just randomly pull down a package from a site you don't know from Adam, and then as root say "Oh, go on then, do whatever you want" is plain madness, but then, you guys are going to flame me to death anyway, so perhaps I should just go and be quiet somewhere.
This is another good reason for .deb.
They did not invent new format. So I can read .deb from Windows as easy as from Linux.
$ PATH=/usr/executables:/home/myname/executables NAME /home/myname/executables); NAME)
% (set path = (/usr/executables
Why do you need a database? If every software bundle ends up in one of very few places, the list of these places becomes your PATH.
Also, "owned by root or by me" is wrong.
--
C'mon, it's nice to have some choice, but do we really need this many formats? Having so many formats just makes compatibility more difficult -- your computer might communicate with one format, but someone else's computer might think in a different format. Let's stick with the oldest, proven format: ARC. It has a track record that no other format can beat; it's certainly been around longer. And just like UNIX-like operating systems beat out newcomers like Windows and MacOS, ARC beats out unnecessary new format like "tarballs."
I started using Linux with RedHat and later moved on to Debian, just because I had a slow connection and the Debian CDs had more stuff on 'em. Debian 2.0 was great, but as soon as 2.1 came around, my computer was filled with redundant files, several different versions of the same libraries, and depend conflicts everywhere. Eventually I gave up on using the packaged system and stuck to compiling everything myself.
-Splat
deb meta packages!
The current Slashdot moderation system is made by gay communists!
The biggest complaint I hear about installing stuff from newbies and mass market audience-types is that they can't find stuff once it has been installed. They just click on their little RPM icon in Gnome/KDE, watch the progress bar, and then wonder why it hasn't been added to their applications menu.
;p
These people aren't going to be typing at a prompt anytime soon, so something as simple as typing the name of the app at a prompt isn't an option.
To simplify stuff for these users, we really need an advanced rpm (or equiv.) tool that figures out where the executable is, and then places an icon for it in the Gnome/KDE applications menu. This obviously isn't as simple as it seems
Ok I am sick of ppl bitching about shit they know nothing about. "RPM sucks" for example all of the arguments made for this are bullshit.
1. The Debian ppl. "Well I can do apget -install" its called rpmfind 'packagename' (and yes this will satisfy the deps also).
2. The "I only install from source" ppl. Ever hear of a source RPM? Or could you not figure out how to unpack it?
3. The "Well I have to be root" ppl. Build the RPM yourself you whiny fuck.
4. The "It doesnt check against libs I installed from a tarball" ppl. Well keep up to date go and check out RPM 4. Also dont be a jackass and mix and match across your system if possible, build the damn RPM.
In The Reality That Is The Desktop, the most important thing is for ordinary (aka non-geek) users is the ability to install/deinstall absolutely any software without penalty or pain. This concern overrides security, it overrides performance, it overrides more efficient usage of resources, and overrides just about anything else. Period. In the discipline of engineering, it is understood that you trade off one thing for another to achieve the necessary goals. In The Reality That Is The Desktop, you trade off the more efficient usage of resources that dynamic linking provides with the robustness of installation that static linking gives and end users requires. Right now, there is such intense fear among windows users that anything they do, any upgrade they make, any new software they install will, in their words, "screw up my computer". So, your average joe computer user will not think very well of Linux when, on Christmas morning, RPM reports that Barbie Magic Funhouse refuses to install because it conflicts with Evolution. Once again, this is The Reality That Is The Desktop. In order to succeed in The Reality That Is The Desktop, one must statically link, as it is the only thing that insures the software will actually install without destroying existing software or precluding the installation of any future software. Dynamic linking simply does not fit in with a healthy model of average joe, consumer desktop computing. Ask 1000 people outside of a CompUSA if,given a choice, whether they would rather have a computer that uses less resources (RAM, disk space, etc) or a computer that will let add or delete absolutely any piece of software without destroying previous software or precluding the installation of any future sofware. I guarentee you that at least 95% of the people will choose the second option. They have all had their share of windows doing unacceptable things when adding or removing software, and they will not accept the unacceptable from an operating system touted as superior to windows. Anyone who argues otherwise does not understand the desktop market and probably has no business whatsoever trying to bring linux to the desktop. Static linking not only provides robustness of installation, it also adds an element of ease of use, too. To deinstall a statically linked program, a user only has to click on the program folder (which can be placed in any damn directory the user chooses) and drag to trash. Empty trash, and you deinstall program. Ridiculously simple and keeps consistency with the UI concept of getting rid of something by dragging to it trash. To install program, the user copies the program folder from CD-ROM to wherever they want it. That's it. To install from internet, the user only has to download and unzip the program folder, then place the program folder where you want it. Simple and quite effective. These are the steps that must be taken for linux to succeed in The Reality That Is The Desktop. Oh, and whether you agree or disagree with me doesn't matter. 'Cause I've got the code.
It might just be me being slow, but when I was at a Australian Unix Users Group conference in July they had people from Red Hat, Suse, Caldera and TurboLinux who all raved about this thing called the Linux Standards Base which is meant to stop vendor dominance and allow things like a standard package management system despite distribution...
Ever heard of the MentalUNIX Packaging System(mpkg)? It takes a radically new approach to packaging. It's truly amazing what it does. The site is at
/home). It then checks the binaries against a build in database of known software, and can ad the program to the database. So, you can have rpm, deb, and plain ol soure code distributions that CO-EXIST! i suggest that you join the mailing list, and read the site. it has lots of information. Sccording to one somebpody said on the mailing list, sometime this week a detailed mpkg spec is going ot be released.
http://mentalunix.sourceforge.net
They currently have a 4 or 5 page "mentalunix paper" in the entire distribution, with a small part on mpkg. From what I've read(in the paper and on the mailing list), mpkg is going to be amazing.
No more binary packages! Everything distributed as source code. The nice thing is that it can be interactive. yes, interactive. If you load up the packager with the normal options, it will load up a simple console GUI(they are supposedly going ot make a Gtk+ based front-end too), and you can configure the program. It stores everything as XML. The congfiguration is handled in a config.xml file, the interface in interface.xml, the dependencies in dependencies.xml. The interfaces will be build using XML, TCL, PHP, and javascript(well, XML and any of those languages added). Imagine -- The kernel pacakge will have xconfig load when you open it! mpkg will also feature a daemon that montitors when new programs are installed in the the standard directories(everything but
-------------
HAL 7000, fewer features than the HAL 9000, but just as homicidal!
Do you want to have clean installation and deinstallation, or do you want to have your choice of a dozen distributions, an equal number of stable kernels, and an effectively limitless number of end-user configurations? Yes, if the Linux directory, config file, and system library versions were perfectly consistent, it would make it easy to add and remove entire packages of software at a fell swoop without concern for the consequences. However, it would also make the system as static and constrained as Windows or the MacOS.
For some users, this might be a good thing. Those people, IMHO, gravitate towards Red Hat. Others, though, may want the freedom to occasionally try out a development kernel, or use a non-standard partitioning and configuration to squeeze a few more Apache page hits out of that old PII box. This is where source or binary tarballs are nice and easy, and give a quite adequate amount of control.
For stuff that isn't packaged with the applications, the package format should contain version information and checksums for any other files it depends on. It should declare those dependencies. The operating system should then be able to identify what is needed, possibly fetch it over the Internet, and give the package access to those files under a symbolic path name.
Such application bundles with dependencies should not (normally) be allowed to access the raw file system for their installation at all. In fact, even most applications should probably not be allowed to reference absolute pathnames. All references should be through symbolic paths. That way, one actually has a prayer of figuring out what the thing depends on, and it would also help with security.
Furthermore, the notion of "install scripts" is broken because it is difficult for anything to figure out what went wrong in the bowels of some script, and because scripts may do things to the system that are difficult to undo. Information about how an application bundles and their needs should be entirely declarative.
Another way of looking at that is that applications and application installation needs to work similar to objects and software components. In the past, programs consisted of functions that looked for, and modified, global variables all over the place. These days, good software components have well defined interfaces, get access to their environment only through those interfaces, and rarely use global variables. That's the kind of change that also has to happen at the level of applications.
The system that is closest to that in many ways is Sun Java: with jar files and the JavaBeans standards, there are well-defined ways for software to get installed and interact with the rest of the system, yet the environment can limit what new software components can do. We need something similar for Linux packages. That would also require additional naming and name translation support for Linux, similar to what Plan 9 offers (however, Plan 9 never adopted a good way of packaging applications based on their naming model--a shame, they were pretty close).
Ask any warez d00d what the three main packaging formats are and he wont tell you tar, debian or RPM.
Lets take a moment to acknowledge the other formats in widespread usage at the moment: ACE, RAR and ZIP.
Seriously though, those amongst who even know what an RPM is are in the small minority compared to the unwashed ZIPophile masses. In this light, was this file-format problem really a relevant issue to raise?