Slashdot Mirror
Cross Platform Packaging: A Dream Or Something More?
stevenl writes "A new project on sourceforge has just been set up for a cross-platform packaging standard. Whilst there isn't much there at the moment, plans are to produce a standard that will allow people to use it even if they have no binary utilities or a compiler to compile one with, and it's expected to be platform independent whilst still being lightweight. What's people's opinions of the cross-platform aspect taking off, or will we see another situation like we have with DPKG - great packaging sysetm, but not widely used due to the inferior (but still good) RPM and proprietary things like installshield?" Frankly, apt-get [?] does just about everything that I need - but I'm curious as to what people about something like this actually working - is it a pipe dream? Or possible?
I don't know whether you'd ever get all the *NIXes to adopt one package format (heck, not even all of the *NIXes that use the Linux kernel use the same package format, so far; is it even possible to generate an RPM that works, for a given instruction-set architecture, on all distributions that use RPM?).
It's probably even more unlikely that you'd get Windows, or MacOS Classic (MacOS X might be considered "one of the *NIXes", although it may be different enough from other *NIX-flavored OSes that it'd be even less likely that it'd adopt some standard package format).
It might be possible to have tools such as Easy Software Product's Package Manager (as mentioned in another posting; ESP are the folks who do CUPS) work with various non-*NIX packaging tools, as well as handling the various *NIX package formats it now handles (debs, RPMs, SVR4 packages, IRIX packages of some sort, HP-UX packages of some sort, source tarballs).
Some tools for packaging on Windows include MindVision's Installer VISE (available for Windows and MacOS), for which "qualifying shareware and freeware developers" can get a free license (it's what the GTK+ and GIMP for Windows uses), and Nullsoft's "SuperPimp" Install System, which is also free. (I've not used either of them, so I can't say how good or bad they are.)
Well, there's a tool called nmake, which comes as part of a package called "Visual C++" from some company up in Redmond, Washington that has done some software for Windows; its makefiles aren't exactly like those for the various *NIXes (but those aren't all the same, either - you have System V make, Sun's make which is a superset of SV make, GNU make, Berkeley make, etc.).
It's not clear that it's a package manager's job to deal with the differences between the "make"s on various platforms.
Want to make $$$$ really quick? It's easy:
1. Hold down the Shift key.
Its called the BSD ports system. It really shouldn't be that hard to get it to work on Linux.
Also, the executables that would get distributed will likely be tailored to its host platform. Many programs will utilize the differences between these platforms. Again, I bring up the example of the Windows Registry. Many applications in Windows depend upon the installer setting up Registry keys that are accessed by the executable. How do you rectify this in *nix? Or the MacOS? Or with the ever growing number of embedded apps?
I'm afraid that program placement, management, configuration, etc. hits so close to the core of what makes a platform that this project will be difficult to complete (and be useful).
Here's a metric we can use to see if ever succeeds: Will developers throw away InstallShield and rpm to use this?
Styrofoam Peanuts are the ultimate packaging material. They can be used to package software for Linux, Windows, MacOS, *BSD, BeOS, and more.
What we need is a packaging system that can correctly detect whether or not dependent packages are installed without having to have a database. The package manager needs to be aware of the differences between platforms.
.deb or .rpm file is available right then, or because you have a local patch to fix a bug you need which isn't important enough for enough other people for the author(s) to fix right now (or maybe is to complicated for them to figure out how to roll it back in without breaking things for other people that you don't happen to need to worry about). Even buying software that uses install shield or some other installer will mess up everything.
The problem is, inevitably, the database will get out of sync the moment you have to compile something from source because no
Once the database is out of sync, then new problems come up, and those are easily fixed by forcing an install or installing from source, and then it just gets worse.
Without a database, it would mean the installer would have to have a way to detect whether the dependent thing is installed or not, and in the correct version. I won't say that would be easy, but it is what would be needed. Until then, based on my past experiences with Redhat's RPM, I won't at all be interested in a fancy packaging system.
Conformity is the jailer of freedom and enemy of growth. -JFK
The prblem with install incompatabilities is really only one of our own making. The problems primarily lies with differing directory structures, system batch files (almost solely involving the init sequence) and available libraries and their version conflicts. All of these can be easily overcome. The last is easily fixed by allowing all versions of libraries to be installed such that they have different names and/or reside in different locations. In this way applications can be very specific about the versions of libaries they use. And programs wont break because a new version of a library has been installed Iin the Windows world this is know as .DLL Hell. This is not such a great problem with Liunx.
Next, the batch files, primarily the one involving the init sequence, are really a minor issue as theer is agood bit of standardization here, but not enough, and a solid fixed standard needs to be put foward and followed. I don't see how else to get around this other than participating in a standard.
Finally, the various directory structures cause problems for applications because they can't find files, not knowing where they are located. Imagine for a moment that wasn't a directory structure at all and all files resided in a single directory. In such a caseeach and every file must have a unique name. Well, this is actually how it is now if you just think of a path as merely a files name. And so the problem lies in the fact that the names don't stay the same from system to system. This can be fix by either everyone following a strict FHS (file hiearchy standard) or by having a single repository directory where a uniquely named link is placed pointing to the needed files of a package.
Think abou it!
:T:R:A:N:S:
This is one of the reasons why I hate VIA: because they do everything so bass-ackwards.
"Ancillary does not mean you get to rule the world." --U.S. Circuit Judge Harry Edwards, speaking to the FCC's lawyer
I disagree. Although some programs can be run over the Web, why would you want to? If I had the option to run a word processer program, or a word processer applet, I'd chose the program any day. Why? Because of the speed/security aspects. I really dont like the idea of running executable code from the web everytime i want to do something, can you imagine the fun that hackers would have with that?
/rant
There's more programs that couldnt/shouldnt be run from the web than ones that should. Can you imagine trying to run Quake over the web? What about other processer intensive applications?(seti@home, apache ect...). I dont see a day when people will give up performance/security just so that there can be a unified OS......I just cant see it.
-Bucky
The few, the proud, the conservative.
-Bucky
The thing that people forget is that this is a good thing. What Linux needs is to develop a cross platform packaging system such as this so that the web can utilise it, and so that the Linux system is at the centre just when these new developments are taking off. The future is OS independant. If Linux is to survive in such a world, it needs to be independant too.
KTB:Lover, Poet, Artiste, Aesthete, Programmer.
KTB:Lover, Poet, Artiste, Aesthete, Programmer.
There is no