Slashdot Mirror
How to Make Easy-to-Package Linux Software
jmmv writes "The packages in any Linux distribution (or other operating systems) are a master piece to let the user install any program he wishes as painlessly as possible. However, the creation of these packages is not always free of problems. Usually, the packager finds that the program he wants to package suffers from a series of pitfalls - either conceptual or related to portability - that make the packaging task harder than usual. This is why I decided to write an article (published at ONLamp.com) summarizing these problems and proposing several solutions to each of them, aiming to make the life of the packager simpler. I hope it to be of interest to free software developers and also hope that they understand some of the issues and try to fix them in their creations."
http://www.autopackage.org
"A truly wise man realizes he knows nothing."
This is because amiga .library files were a bit like C++/COM objects: each library had a jumptable and base address. Jumptable entry offsets from the base address called LVOs (library vector offsets) were public and known. All library calls were indirected through the jumptable. So the compiler knew from the #pragma in the header to compile a call to, say, intuition.library/OpenWindow() or whatever (my amigaos zen is, uh, rusty, for some reason), to a jump to address IntuitionBase minus LVOOpenWindow, which was an entry in the jumptable (which grew downwards in memory, hence the minus), which then jumped to the actual library function (So every shared library call was a teeny bit slower than a direct function call (but even in those days of 7MHz computers, people seldom noticed)). And the application could pick and choose when to call OpenLibrary() to do the dlopen()-like operation, with very little hackery.
.so files, which are shared object files which are actually dynamically linked at load time by the ld.so program. The recent adoption of "prelinking" of linux .so files is a bit similar if you squint, though.
.library file format specified a version number, higher numbers "win". But total binary backward compatibility could be maintained (with effort on the library author's part) even in the face of API modifications in the library, because binaries compiled against the earlier version would expect the old LVOs, so the the library author could just use new LVOs for his new API, and maintain the LVOs for the old API as wrapper functions for his new API (or made them bomb out with an error if he was too lazy to maintain backward compatibility, which is still more graceful than a typical .so or .dll "silently do the wrong thing").
Actually, the WHOLE AmigaOS was like that. Address 4 in an Amiga process's memory map always pointed to AbsExecBase, the base address of the pre-opened exec.library (the AmigaOS pseudo-microkernel with interrupt handling and task switching stuff and so on). The process could then find exec.library/OpenLibrary() to open intuition.library (gui) and get IntuitionBase, dos.library (DOS) and get DOSBase, and so on.
This is VERY different to
Another ramification of the LVO system was that library versioning was pretty easy. The
You may be interested in relaytool. See http://autopackage.org/ for info.
I think what OP meant was that Mplayer released a tarball, then found some bug in it and released a second one with the bug fixed but the same filename. Any MD5 hash of the first one will fail on the second one. Gentoo uses a MD5 hash to verify that the file is the right one.