In this article, SAMag will explore OpenPKG, a software development and packaging project initiated by Cable & Wireless, an international ISP. The OpenPKG project began in November 2000 and has grown into a collaborative software development effort managed and maintained by many. The project aims to create a modular and flexible UNIX subsystem for cross-platform software packaging and installation.
Cross-Platform UNIX Software Packaging with OpenPKG
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Ugh… they chose RPM…
You know, I wouldn’t mind rpm so much if you could extract the files contained within an rpm with standard Unix utilities (like ar/tar in the case of Debian packages, or just tar in the case of Solaris/FreeBSD) I don’t even mind the use of cpio over tar in rpms, but needing something like “rpm2cpio” to get at the files in RPMs is a major hassle that would be unnecessary had they been thinking a little more when they designed the package format.
They chose RPM b/c it’s the closest thing to a cross-platform standard available today. It’s only logical to pick a format that’s in widespread use, over say debian packages. RPM’s got the commercial backing, some companies distribute their binaries exclusively in RPM format.
As far as extracting files from RPMs, I believe that Midnight Commander has builtin support for such things, and it is included in several mainstream linux distros and available to almost every flavor of UNIX. Also, it should be quite trivial to wrapper rpm2cpio in such a way as to emulate tar using a perl or python script.
I hate to see people bash RPM in itself, in fact it is a very capable packaging format, and when you couple it with apt-get it works just as well as debian.
Just my 2 cents
-bytes256
of course, if you wanted to extract the files you could always use a different method for getting them in the first place. As the article stated, they chose RPM because it’s the only package format that meets their requirements. ‘Getting at the files’ wasn’t one of the purposes of either this effort or RPM.
RPM can work, if its done right and there is the hitch.
Same crap, different name. Doesnt Intergrate with the system and forces its own layout mentality on you. Mind you that the layout is almost exactly like how i treat AppDir’s on my systems, except mine are entirly self contained, and with a few exceptions(gnome apps are the worst in the regard) can be moved to different Directorys/FileSystems/whatever.
My take:
CoolFactor: semi-platform independant, more sane file layout. Might be nice to have when your Platform doesnt have
the right mind to include a decent source tree(ie ports)
Cons: just another packaging format. Solve’s very little.
i think they missed the boat here. rpms can be very frustrating. in fact they usually are. i used red hat, mandrake, and suse for a while and the main thing that made me look for something else was the way they managed rpms. everything was fine so long as you could find a distro-specific build but to build something yourself usually still involved searching out several rpms and crossing the fingers.
i moved on to debian and eventually gentoo. i am yet to be disappointed. with 1 simple command, i can update my entire system. when the ebuilds (gentoo) aren’t available (which is rare), you can be good money that 99 % of any dependency related apps/libs are so you dont have to spend all day searching for that one missing piece. and once you find your app, can write your own ebuild very easily!
given gentoo system, is a rip off the bsd ports deal, but its a damn good rip. i’m not going to end this and say, “go try gentoo” but if you are interested in package management, you should check out their web site (http://www.gentoo.org) and look at the documentation for portage. it really is a thing of beauty.
It’s very very hard to make a -good- packaging system. If you use a lightweight system like the one in Slackware (basically, a gzipped .tar file with a manifest) you shift a whole lot of responsibility on the user (the one who installs the software), but it also leaves a lot of freedom, too. This approach is simple and it actually works, but Slackware’s package management is, surely, primitive.
RPM tries to be smart, but it fails way too often, and the user does not have the freedom (i. e. not “empowered”) to fix the problems in the installation. In addition to that, RPM still doesn’t have all the feature of the more sophisticated packaging systems, like the ones found in UnixWare and Solaris. HP-UX has an even better packaging system (called SD-UX), that is both smart and fairly bullet-proof.
I have been creating lots of packages both for Solaris and for HP-UX, and am fully aware of their power (in fact, I am one of the few persons in the world, I believe, who creates genuine Solaris patches). In case of Solaris, the power comes at the price of high complexity during the package or patch creation, whereas SD-UX is much more straightforward.
One big advantage the Solaris packaging system has is the support for the Jumpstart infrastructure… but that’s another (long) story.
Is there a reason why the package descriptions are so short
and uninformative. One thing I like about RPM is that you can incorporate a very good description of the package.
You have different fields that contain different kind of description about the bundle, fileset, package or patch. Truth to be said, pkgmk and the rest of the infrastructure doesn’t seem to encourage verbose descriptions.
With SD-UX things are much straight forward in this case, too. There you can “elect” a readme file which you can query from the package in the depot or the installed package. So, if there is a readme, with swlist -a readme (so “readme” is a special attribute passed to swlist that means “display the elected readme file”) – pretty nice.
The Solaris documentation, when it comes to creating packages, is rather bad, and it gets much worse when it comes to creating patches. That might be the reason why people don’t use the Solaris package management infrastructure to it’s full.