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?

Comments

Re:Wouldn't it be cool?

[Guy Harris]

Wouldn't it be cool to include ALL OS's? Not just the *NIX's (getting one package manager to correctly handle both BSD and Linux is a complicated task as it is), but Mac, Windows, etc?

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).

If they could get something that would reliably install stuff under Win2K (InstallShield really doesn't cover it),

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.)

and do compiling for makefiles (I don't even know if there is something to do makefiles in Windows anyway),

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.

Why reinvent the wheel? It has already been done

[VanL]

There are already a number of projects seeking to remedy this situation. The most advanced, IMO, is Easy Software Products' EPM package manager software. Already stable (up to version 3.2) and able to build .debs, .rpms, .tgz, swinstall/depot for HP-UX, pkg for Solaris, and inst/tardist for Irix. If we were all to switch to something like this, the binary format wouldn't be a big deal at all.

Want to make $$$$ really quick? It's easy:
1. Hold down the Shift key.

Styrofoam Peanuts!

[Dominic_Mazzoni]

Styrofoam Peanuts are the ultimate packaging material. They can be used to package software for Linux, Windows, MacOS, *BSD, BeOS, and more.

The problem is in the dependency database

[duffbeer703]

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.

The problem is, inevitably, the database will get out of sync the moment you have to compile something from source because no .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.

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.

I hate cross-platform packaging.

[AFCArchvile]

Ever tried to download a driver set for a piece of hardware, only to find that the package is many megabytes large, and contains drivers for every OS known to man? Well, I'm sick of it too. Just recently, I had to download a sound driver for the VIA Southbridge, and the driver package (68MU111B.EXE) was 8.91MB (yes, almost 9MB, that's no lie). That self-extracting package contained drivers for Win9x, Win98 Second Edition, Windows ME, Windows NT 3.51, Windows NT 4.0, Windows 2000, OS2, DOS, and Linux (Caldera 2.2 and RedHat 6.x, specifically). If those drivers had been packaged separately, the drivers themselves would be 240 KB, 84 KB, 79.2 KB, 164 KB, 6.32 MB, 79.2 KB, 240 KB, 415 KB, and 139 KB; respectively. The largest sized driver set in that package is the NT4 driver set, weighing in at over 6 megabytes (most of that size being the separate setup program). If VIA had split up the drivers by OS and used a less user-friendly strategy (ditching the setup program in favor of .INF files), then I would only have to download 79.2 KB.

This is one of the reasons why I hate VIA: because they do everything so bass-ackwards.

Yes, because OS's are becoming irrelevant.

[Kiss the Blade]

We all know that the future does not lie with any particular OS. We have been repeatedly told this for some time now. Other platforms have been doing thier best to grab this, as we can see with Solaris (Java) and Windows (.NET). In the future, which OS you run will not be important. When I use my computer, I already spend the majority of my time on the web. In 10 or 15 years, things will be fast enough for entire applications to be run on the web, and my local terminal will just be used to store data and connect to the web.

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.