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?
Use stow :)
/usr/local/stow and then typed stow IBMJDK1.3
/usr/local/ - bin/java etc - and as soon as you want to upgrade you can remove the symlinks and so on.
/usr/local at the very least. It's still not perfect (for example, xmms plugins), but it's not horrific.
/usr/local/packages/IBMJava1.3 and then do something like stow that would create a mini-debian package and then I could install that, I would have even less trouble. And it would work well for all software that uses configure or anything similar.
It's not perfect (because of the fact that the things you install don't auto-handle dependencies) but it gives you a nice package style view.
For example, to install IBMs JDK on my box, I just stuck it in
And stow then symlinks the files etc straight into
It stops cruddification of
The best bet would be something like this but to generate packages - if I could pack something into
Or not. I don't necessarily install only source packages, even on BSD or Linux...
...and, from what I see on the Ethereal mailing lists, I'm not the only one; there are plenty of people who install binaries of Ethereal, for example.
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.
http://www.easysw.com/epm/index.html
Want to make $$$$ really quick? It's easy:
1. Hold down the Shift key.
Want to make $$$$ really quick? It's easy:
1. Hold down the Shift key.
Indeed - right now the only way is a proprietary installer format (e.g. InstallShield's java-based installer, which installs its own JRE as necessary).
.msi) so most packages are migrating to that anyway.
EPM, posted earlier, looks pretty good for the Unix world, since it already supports quite a few platforms such as Debian, Red Hat, Solaris, HP-UX and Irix. This is unlikely to ever cover Windows - Microsoft has its own recommended installer format (Windows Installer,
Thanks for the pointer to stow (lhttp://freshmeat.net/appindex/1999/09/23/9381254 46.html) - it ooks very useful for software that comes in .tar.gz files or proprietary installers. I like the way it just adds the minimal set of features necessary, and encodes the installed files as symlinks for easy removal later.
Its called the BSD ports system. It really shouldn't be that hard to get it to work on Linux.
This is very easy to do. Here is a way I have thought of I'm sure other people can come up something even better.
/opt or /usr/local.
./man ./etc ./var ./lib
./var is actually a symlink to /var/nameofapp.ver
/usr/bin /man /etc or whever (there are already a couple of systems that do this).
/opt directory tells you every package installed.
1) Every application must reside in it's own directory in
2) The directory must be named nameofapp.ver
3) Inside the app directory ther may exist
4)
5) all the files are them symlined to
The beauty of this system is that it's very easy to implement because it's just a matter of specifying a --prefix.
If you need to roll back to a previous version you simply relink the old directory.
You don't need a database just doing a ls on the
You don't need to compile in fact you can use httpsync or cvsup to fetch the files directly from a url.
Easy, simple, human readable, human fixable what else can you ask for.
War is necrophilia.
Your argument approaches irrelevancy if and when networking becomes "pervasive". Does Picard "run a program" on the computer? No, he just tells it what to do, and magically it works. At some point in the future, it is not only not improbably, but probably definate, that we will have pervasive, seamless, computing all around us. But by that time the very concept of installing a "software package" might become obsolete also ;)
It's 10 PM. Do you know if you're un-American?
Actually, we've been looking into adding support for Windows-native distributions in EPM. The current offerings (InstallShield, etc.) are not suitable for large projects and can't be automated like they can under UNIX...
I print, therefore I am.
How about this... In order to preserve the source of a closed source system:
.tgz file. Then I choose my compiler. There is a program that takes the chosen compiler (on the source system's disk) and puts it into the emulator... then it packs the emulator/compiler with the tgz of the source into a single binary file for a specified OS.
Package two files as one. One file is the encoded source code (for closed source) or just a tgz with all the source (for open source) we'll call this Part A. Then add Part B, an operating system emulator that is made to do only a single thing: run a fake os, very small, and execute a compiler that is built into the emulator to compile the source and then spit out the final binary onto the system...
For instance. Very simple hypothetical example.
I write a program called "DecBin" that converts decimal numbers to binary. I take the source files and put them in a
Now whenever somebody wants to install my program, they execute the binary. The binary unpacks the tgz and then runs its emulator/compiler on the source code and then spits out the binary as a.out or something.
Just an idea...
Wouldn't that make the file sizes bigger if you were to include all OSes?
Ant(Dude) @ Quality Foraged Links (AQFL.net) & The Ant Farm (antfarm.ma.cx / antfarm.home.dhs.org).
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?
I don't see any mention of whether this is UNIX-specific or all-inclusive. Is a packaging system that uses the same specifications for UNIX/DOS (or Windows, if you prefer)/MacOS/etc. feasable. Certainly it's possible (there's gcc for DOS, for example) to have UNIX tools compiled for filesystems organized in different ways, but this is a packaging specification.
Also, how would it handle dependancies? A widely available version of X11 for BeOS, for example, puts files in different places than X11 for Linux does (AFAIK).
This doesn't sound feasable for anything other than a strictly UNIX platform, and then what do we have? Yet Another Packaging System.
Styrofoam Peanuts are the ultimate packaging material. They can be used to package software for Linux, Windows, MacOS, *BSD, BeOS, and more.
...is a promising one-click web based multi platform installation solution that has just recently been released. Of course it installs Java applications, but Java's multiplatform already so it's perfect. It still has its limitations compared to native code but that gap is narrowing with every release. (I am not affiliated with Sun but I am a Java coder :)
"Mind, as manifested by the capacity to make choices, is to some extent present in every electron." -Freeman Dyson
What's the difference with OpenPackages.org?
--
Donate free food here
does apt-get work on windows? on the mac? the requirement here is cross-platform as far as I know apt-get doesn't even work across Linux distros...
.jar files, but it seems like you want to be using C++. Another option would be to have the installer go grab the files off a server if it doesn't have the ones it needs for the current platform.
Anyway, if you can't assume access to a compiler, the only thing you could do would be to ship binaries for every platform. And as you can probably tell, that would suck. I would say just use java and
Of course, that would require that you have binaries for that platform, but, its better then nothing.
Amber Yuan 2k A.D
"and dear god does this website suck now." -- CmdrTaco
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
If they could get something that would reliably install stuff under Win2K (InstallShield really doesn't cover it), and do compiling for makefiles (I don't even know if there is something to do makefiles in Windows anyway), I'd definitely get this package manager.
- I don't care if they globalize against free speech. All my best free thoughts are done in my head.
I like the idea. When I wanted to package OpenSSH at work, it's one thing to build it on several platforms... But it is quite another to package it.
:)
I like the idea of not having to know how to make an HP Swinstall package, a Sun pkgadd package, and others. Right now, I need to sholder tap someone to have a package made for a packaging system I am unfamilier with.
As for Windows flavors... I find myself wondering why even port anything to Windows... let alone package it. But of course, that is entirely biased.
This sig intentionally left blank.
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
While at first it seems to be a wonderful idea, it is in fact not. Keeping something like tar or bz2, zip, etc... standard is important but not a packaging technique or manager. Different operating systems are too different, and would never be accepted on non-open platforms. If a standard packaging system is to be done, do it for linux and unix like operating systems only. Then if non-open platforms like it, they can adopt it on their own. I personally think the best thing that could happen would be for debian, redhat, the linux standard base, and others to get together, take features and components from rpm, deb, and create something new that everyone can agree on. From a developer and corporate standpoint, making packages for rpm, deb, and tar is too much of a hassle and not practical. Everyone needs to put aside their differences in opinions and come to a compromise that can benefit everyone. There ought to be a standard packaging system for binary data and stick to tar for source. If average computer users are to ever migrate to linux, this has to be done. Enough with all the ghettoness and disorder.
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
You know, if you are going to imposter-ize me, you should wear ankle guards, because when I find you I am going to unleash an army of rabid she-gnomes on you.
-perdida
Goat sex free since 2001