OpenPKG 1.0 Released

Ralf S. Engelschall writes: "I'm proundly announcing today the release of OpenPKG 1.0, the world of cross-platform RPM-based Unix software packaging. A flexible and powerful software packaging facility, OpenPKG eases installation and administration of Unix software across several platforms. It primarily targets the Unix platforms FreeBSD, Linux and Solaris, but is portable across mostly all modern Unix flavors. OpenPKG was created in November 2000 and after over one year of development it is already a mature technology in production use. It is available as Open Source and is further maintained by both my development team at Cable & Wireless Germany and our contributors. For more details visit openpkg.org and ftp.openpkg.org."

Congratulations Ralf.

[bodin]

Let's just say that Ralf is the commited guy for standard packages.

http://www.openssl.org/ [openssl.org]
http://www.modssl.org/ [modssl.org]

To say a few.
He's the guy that wrote mod_rewrite back in the old days. Tough guy.

Re:Sounds neat

[arthurs_sidekick]

errr, compare citrus to citrus, chum: RPM is to APT as .deb is to (e.g.) gnorpm -- .rpm and .deb are package formats, gnorpm and apt are tools for managing those packages (and IIRC one can now use rpms with apt -- Linux Mandrake?)

APT is a tool for managing DEB packages, it is not a packaging format itself.

don't be spreading misinformation ... makes you look ... well, like someone you wouldn't want to look like.

Re:hmm...

[Anonymous Coward]

A someone else has said, the intent is that the source code will be there, therefore allowing use of automake et al in the build process.

Doable.

Lets hope that there is sufficient take up to allow proper dependencies to be included and found.

It's too bad

[DaveBarr]

There's two main roads to take when trying to develop a solution for this problem. The first way (the OpenPKG way) is to pick a package system and use it across all your platforms. This ensures that your package system will be incompatible with the majority of your systems. (As a side note, it is too bad that they chose RPM on top of this). However, you at least get to use one tool for all the stuff you add.

The other road is to develop a meta-package system which "wraps" the existing native package system. This ensures the two package management systems don't stomp on each other, and allows you to interoperate with the native package management system (Sun's pkgadd, HP's depot, SGI's inst, etc). As many of us know it can get extremely ugly when a package management system starts getting out of sync with what is actually taking place on a filesystem.

To put in a shameless plug (I'm only a customer) for some very cool quasi-commercial effort in this area, we use software packaged by The Written Word [thewrittenword.com]. (yeah, strange name). Their software is of the latter philosophy.

I say quasi-commerical because while they sell distributions packaged on their tools for profit (and provide support and updates for their software by subscription, allowing me to concentrate on my normal duties, not worrying about recompiling this and that when the latest exploit comes out) they are actively involved in open standards-based efforts to develop a true cross-platform open package management system. And by my understanding are committed to switching their system to an open standard once it is standardized and of a sufficient functionality.

Either way, as Debian users know, the important part is not that you pick a good package system. The important part is that you pick a system that is well maintained, so when the next fix for exploit comes out you know that within a short period of time you can run {apt-get,pkg-inst,whatever) and get a working fix installed.

The biggest problem with many of the other package systems out there (Sunfreeware, Red Hat Contrib) is not that the package system is necessarily bad, it's the fact that the people don't maintain the packages. They're either woefully out of date, or compiled with beta snapshots of gcc or libc, have incorrect or missing dependencies, or simply haven't been tested.

The problem with this...

[printman]

The problem with this is that is requires the RPM software on all target systems. This won't be popular with a lot of sysadmins because most want to stick with the vendor packaging systems whenever possible so that only 1 install tool needs to be learned and so that dependencies between packages are handled consistently.

RPM's source-centric view (where you have to rebuild everything from scratch all the time, making development of the initial distributions extremely time consuming) is also a major problem, because a lot of packages take a long time to compile (we have one that takes several hours on older hardware), and you may be testing fixes, etc. that only affect a single executable in your package.

Anyways, for people that want something a lot more portable and flexible, see my (also free) EPM software at "http://www.easysw.com/epm/". It does native RPM, DPKG, *BSD pkg, System V pkg, IRIX inst, HP-UX swinstall, Tru64 setld, and AIX installp packages, or so-called "portable" install scripts with tar files, all from the same software description/list files. Utilities are provided to automate the building of the list files from already-installed files/directories (the classic RPM BuildRoot stuff) or by intercepting "install" commands, making it very easy to create and/or maintain them.

Re:Time loss

[ink]

So it doesn't automagicly resolve problems, like apt-get does, which is why, having used both, I prefer apt-get.

For the (hopefully) last time: APT HAS NOTHING TO DO WITH THE PACKAGING SYSTEM other than requiring the package system to know about dependencies. APT works just fine with RPM, just as it works fine with debs and I see no reason why it couldn't work with OpenPKG.

FreeBSD pkg_add

[Shooter6947]

How is this new system different/better than the FreeBSD pkg_add? When I want to download an install a precompiled binary I just type (as root)

pkg_add -r gnupg

for instance and the binary package gets automatically ftped down, unpacked, and the pieces installed to the correct locations. With thousands of FreeBSD ports already set up, why should I or anyone switch to this new system?

Has anyone actually read their documentation?

[Florian]

If you had, then you would know that

• it uses a modified, incompatible version of rpm which will will coexist with "normal" rpm in case the OS it includes the latter. (Unfortunately, the OpenPKG executable is called "rpm" as well, but resides in a different path)
• it builds its own repository/package database separate from the core OS packages
• it uses its own particular filesystem layout
• it doesn't provide apt-like functionalitySo OpenPKG does not replace existing package systems, but is meant as a secondary package system for OS-independent userspace tools (thus allowing to share installed packages across different Unix-like OSs). It breaks all Unix/Linux filesystem/compatibility standards, creates headaches by installing itself as a secondary package manager/database, and thus is unlikely to be widely adopted. (Seems rather like a possible solution for sysadmins who want consistent application installations acrosses different flavors Linux/FreeBSD/Solaris).

Congratulations, ichimunki

[MadAhab]

Congratulations, you just described the FreeBSD ports system.

Re:Congratulations Ralf.

[xsbellx]

Well how about AIX for one. Since version 4.0 of AIX, IBM has NOT include a "C" compiler as part of the base operating system. I agree, it can be purchased or GCC can be installed but both of these have negative implications in a corporate environment.

Purchasing a C compiler costs money and bean counters and the like object to anything that adds to the cost of a box. Using GCC, or for that matter, any software that is not supported by a vendor, is usually strictly forbidden.

This policy or a similar type varient, has been the standard at almost ALL of my employers (3 fulltime and 14 contract over the past 22 years). On the other hand, development boxes are usually not quite as vigilantly monitored.

I am not saying this good or bad just passing along some anecdotal evidence that:
if (sys == Unix) {
C compiler == TRUE
}
is no where near as true now as it once was.