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

COOL!

How very useful.
Whilst Solaris does have package management, it's not as good as RPM.
Of course, now all you have to do is convince sun to support it :)

Congratulations Ralf.

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:Congratulations Ralf.

While I appreciate this work, what I really don't understand is why not work on building a tool that doesn't rely on "packages" so much as it relies on source tarballs that are independent of any packaging system.

What *I* want (and yes, I am coding this myself) is a system that only knows as much as necessary to get the package from its original source in the rawest form available. Then the system takes the package and builds/installs it using a user account set aside for the purpose of installing non-base software.

Optimally the package system will help the user write a shareable makefile of sorts and save/share that with other systems that user has and with other users. Then, once the build is done, you zip the build directory back up so that if you should need to work with them again the whole mess is handy.

At its very best the package system recognizes source sources such as tarballs via FTP and HTTP, but also CVS. And finally some hooks to external information sources (announcement lists, a central log of known changes) so that the user can be alerted to potential upgrades, bug fix releases, and security patches.

One thing I don't like about RPM/.deb/etc is that they rely way too heavily on a database of what is installed to determine what they will install next. If I don't package my "found" software using the package system, this causes RPM/dpkg to start complaining about stuff it doesn't have that I know it does.

Congratulations, ichimunki

Congratulations, you just described the FreeBSD ports system.

hmm...

ok, so in a nutshell, no matter what *nix I use, as long as I have openpkg installed, I can install any package?

In other words, I can burn openpackages to a CD, and install the same packages in BSD, Redhat, and Suse?

Re:hmm...

I don't even know how to begin replying to this, but i will give it a try ;-)

First off, no this will not work. Due to different system calls, C libraries, different architectures (CPU etc), etc etc packages will never be that portable. Java and other (supposed to be..) cross-platform type programs might have a chance, but normal applicaties will not be.

So, if a 'package' is not portable, what good will this do me then, you might wonder? Well the thing is, that previously, you had to make a different 'build and package tool' implimentation for every platform you want to compile your program on. pkg/ports stuff on BSD, other pkg stuff on solaris, apt on debian, rpm on redhat & other linux's.

So this is where OpenPKG comes in. You only need to write the 'build and package tool' implimentation once (a so called .spec file). This 'source package' you can then compile on each different architecture and platform.
(resulting in a binary usable for only that platform).

This makes cross-platform/architecture distribution a lot easier, and a lot easier to maintain.

Time loss

RPM was created as duplication of effort, because Debian wasn't willing to rush a half-baked dpkg. Now it becomes a standard. Reeks to me of Microsoft Windows-like storyline.

Why not just port and use dkpg, apt and associated tools? They were all created to be portable, and are indeed already used in http://fink.sf.net./, http://debian-cygwin.sf.net./ and the like.

Re:Time loss

Right... why not judge the two based on some kind of technical merit, like their features? And it would really be nice if the debian people and the redhat people got together and standardized on the next generation package format that they would both be happy with.

Re:Time loss

Why should be judge them on technical merit? Both are perfectly adequate, and even though .deb may be technically better, the main reason for people disliking rpm is the amount of incompetently built rpms available.

My point is that .deb may be marginally better technically, but it doesn't matter as long as most projects have chosen .rpm, and the cost of remaking that decision is FAR bigger than any advantages.

I have nothing against debs, I like them. I use Debian a lot. I like it. But there really is no point in advocating that everybody should switch to debs, because it isn't going to happen.

Re:Time loss

I'm not even sure .deb is technically better. There's some things RPM does nicely that dpkg doesn't. (For example, the "one big patch" idea in dpkg means that if you're going to add patches of your own to an upstream package, you need to invent your own structure for keeping your changes distinct, and reinvent it for each package, as far as I can tell. RPM deals with lots of patches nicely, and I think it's one of the reasons that there are so many Red Hat-derived distributions.)

Re:Time loss

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.

Uses separate RPM repository, no NLS

I notice that an openpkg-installed package populates their own RPM database, rather than using one that may already be on the system. While this may be due to the fact that they need to store additional information that a default RPM4 database doesn't allow for, it would seem to be a horrible inconvenience to maintain two separate RPM databases... even if one allowed you more cross-platform control.

Also, I thought it interesting that they favor English as the only language used on Unix machines, and chose not to include NLS support in OpenPKG. And they're not even Americans!

Why RPM ?

It really surprises me that they decided to use RPM package format. It surprised me even more that they decided to create "Yet another package system", while there are many very stable and advanced one, that are just waiting to being ported to "Yet another Unix".

My personal experience is
RPM = headache.
APT = a lot of relieve.

mjander.

Duplication of Effort is *Okay*

I've already seen a number of people saying, "Yeah, great, but why didn't you port an existing system [usually Debian's] instead of writing your own solution? We don't need another package management system." This drumbeat of "don't create multiple approaches" opinion continues to get louder, and as it does so irritates me more and more.

It's *good* that there is more than one way to do it. I'm glad that open source not only provides for the possibility of multiple approaches (the built-in allowances for forking), it has a long history of such.

Don't like sendmail? Write a different mailer, and perhaps like postfix it will become popular. Think that the available desktop managers were built wrongly? Try coding one using your preferred approach. Having diverse solutions can help improve them all, as features from one program are pulled into others.

The OpenPKG folks saw a need and decided to base their solution on RPM. You may not think that was the wisest choice, but they get to choose where they apply their effort. There is no One Approach to bind all open-source programmers, no One Application in any given niche to which all should contribute. One of the beauties of OSS is that I can choose where I wish to contribute.

From the faq:

Writing a new packaging tool from scratch was not an option, because it would have required too much time and it was not clear whether we would have been really more successful than others. Instead we picked the solution which provided for all(!) of our essential wishes a good or at least reasonable solution. The RedHat Package Manager (RPM) version 4 is not a perfect solution, but even with its drawbacks and pitfalls it fulfills the fundemental needs of OpenPKG.

I dont know about you but that doesnt really inspire a lot of confidence in me. Essentially this reads to me like they wanted to quickly extend an inferior package management system. *shrug*

RPM?!?!?

bleh... real men/women compile ;-)

come on.. who doesn't like configuring/compiling... it's the best way to install a program... you customize towards your preference... if anything at least use ports instead of RPM :-\

RPM's

I guess people prefer package managers to tarballs. And I guess RPM is the most popular PM and that is why they have chosen to do it. Mircosofty? Possibly/Probbably - good? that remains to be seen. I think I'll let other people try it before I infect my system with it ;-)

Incidently, does anybody think it strange that when we create something not Microsofty it slowly becomes Microsofty?

Why settle on one package format?

The FAQ says that OpenPKG decided to go with RPM over all the others for whatever reasons. What I'm wondering is, why bother limiting yourself in that way? Meaning, isn't it a trivial matter to figure out what package type a file is, and use the appropriate tool to handle it? My point is, I think that rpm, deb, and slackware's format are all mature enough that you can't really argue one over the other without getting into taste. Wouldn't the REALLY smart move be to try to come up with a tool that offers convergence? (not saying that nobody hasn't, but I am saying that I think it's an outdated idea to go with one specific format over any other)

It's too bad

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.

Too little, too late

Nice try guys, but no. Unix is already too segmented and this packaging system will not change things one bit. This is a non-NLS supporting, non-GPL'd implementation of an uninspiring packaging system which may or may not support other versions of Unix besides Solaris, BSD, and Linux. Their FAQ [openpkg.org] even contains the question "OpenPKG breaks with a few things from the good old Unix days. Why?" Thanks, but no thanks.

The problem with this...

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.

Sounds a lot like "openpackages"

When I read the title I first thought about
openpackages "the new standard for open source binaries"

http://www.openpackages.org

I'll never tourch RPM again if I have too

The first time I typed "make install clean" in the FreeBSD ports tree I told myself I'd never do roothat again or RPMs again.

Since FreeBSD can run the huge majority of linux applications that I need/want, i have no need to get into RPM-hell again.

If I need to upgrade a system I use cvsup to apply the necessary patches to my source tree and make the world. If I want to update applications, I cvsup my ports tree and run portupgrade. There's nothing easier and it's very rare anything goes wrong.

So, why build this OpenPKG thing in the first place? VC money down the tubes. I'll keep my ports and packages, but I'll never run RPMs again.

Why RPM?

When I started using Linux, there was RPM, but then I found dpkg and apt and have never gone back.

Last week, I tried FreeBSD for the first time. I was very impressed with the ports tree and pkg_add.

What would be the compelling reason to use openpkg on systems with package managers better than RPM?

FreeBSD pkg_add

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?

But I thought....

... Linux isn't Unix?

Can anyone summarize how this differs from RPM?

I read the FAQs and scanned the slides, but I didn't see how this differs from RPM. Am I just missing something?

With RPM, I have a single source RPM, and can build that to create a binary on (theoretically) any architecture (assuming my spec file, etc, take quirks into account.)

Oh, I see that OpenPKG offers a way to download a file and install it, without explicitly already having RPM on your system. Nice but I'm sure there are more perks I'm missing, otherwise this just looks like a rebranded RPM to me.

Enlighten me, please.

Cross-platform?

How is that when MS says "It's cross-platform: it runs on Win98 AND Win2000" we all snicker, but when somebody says "It's cross-platform: it runs on all flavors of Unix" we don't even blink?

To me, true cross-platformness includes the ability to run on AS/400s, S/390s and VMS. Like emacs or slickedit or... perl?

John.

I'll stick with source thanks

I would much rather stick with source installs!

Wrong comparison here

I see a lot of people here making one big mistake: Comparing this to Apt. Apt relies on files that tell it where to look for a program, then gets this program and installs it. (Along with any dependencies).

This program takes an _already downloaded_ RPM (that's right, just _one file_, at least at once), and then installs it. It doesn't search a centralized ftp for the RPM and then install it.

The real complaint (which wouldn't have had anywhere near the same oomph) should have been:

"Why did they choose RPM over dpkg?"

(Which is only natural because very few people download a .deb and then install it with dpkg)!

Has anyone actually read their documentation?

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

All-leveling Installer

I would like to first point out that I am in no way, experience-wise, able to do this myself other-wise I'd do it...Could some-one make one installer which could install ALL these different types? I know there are some coding BADASSES out here at /. who could. This could be one of the big breaks that could help Linux gain a larger footing in the desktop market (You know, a kinder, gentler, Linux for the masses and in the process, saving the rest of us from premature hair greying). Please! I fear XP!

Already being done

There is a group out there that has been working on unifying the packaging system across all the *BSDs out there. Open Packages [openpackages.org] has already been working on this, and much of the work has been to implement something that sort of a cross between FreeBSD's ports system and Debian's apt.

At first I thought that this was an announcement of that, but now I know that this is a seperate project with different goals.

Stupid, stupid rat things!

Is it just me or is the fact that this thing even supports binary RPM's self-defeating? How is that going to be cross-platform??

Mind you, using the RPM system is pretty self-defeating too.

TWW

Is this open source - or an ad?

Inquiring /. minds want to know.

let's not forget Gentoo

A lot of folks are mentioning ports trees . . . anyone who's taken a look at the GNU/Linux port of the FreeBSD ports tree will note that it takes an incredible amount of hacking to get that tree to work under Linux.

Gentoo Linux (http://www.gentoo.org [gentoo.org]) is building a ports-like tree called Portage, based on Python rather than a mix of Makefiles and shell scripts. It combines the features of cvsup (actually, it just calls rsync; the command to update the portage tree is "emerge rsync"), make install (emerge blah.ebuild) and portinstall (emerge blah/blah). Soon, emerge will have the equivalent up portsupdate.

The system can install source, create bzip2'd tar packages, or, as an option. RPMs.

Crossplatform, I think not...

cross-platform RPM-based Unix software packaging.

crossplatform: [dictionary.com]

software, hardware> A term that describes a language, software application or hardware device that works on more than one system platform (e.g. Unix, Microsoft Windows, Macintosh). E.g. Netscape Navigator, Java.

Using buzzwords, is great and everything if you're a marketing droid, but lets try to be a little more precise among ourselves.

I'm not trying to belittle this accomplishment, and I'm sure it is quite valuable, although I personally would give up apt-get only at gun point and to call something crossplatform that only really ones on one 'platform' is silly.

You know what would make RPM so much better

if RPM had it's dependancies based on _files_ not other packages...then it would work so much nicer, especially with other package systems. My main complaint about RPM is that as soon as I install somthing (such as X, or a kernel) from source that a lot of things depend on, I have to "force" all packages that need it, cause i know i have it.

I mean, how hard is it to add a nightly cron task (similar to locate) that would make an inventory of your files/libraries that RPM could use for dependacy checks?

Also this would make RPM cooperate nicely with other package systems..The point is, RPM shouldnt care where the files came from, just that they are there.

Microsoft is moving to MSI

The one true package format: setup.exe

I assume you refer to the standard name of a Windows installer program. Those may become obsolete, as Microsoft and other vendors shift to .msi packages that use the Windows Installer [a-softtech.com].

Re:Yet another package management system?

Wouldn't it have been smarter to port an existing advanced package management system/format like .deb to other UNIX flavours rather than inventing yet another system? Isn't that some serious reinventing-the-wheel?

Isn't that what open source software is all about? Just as in commercial software, a bunch of different groups work on the same thing in the attempt to be the best, most widely adopted, and thus the standard?

In commercial software, the development and marketing effort goes on only as long as the company can afford it, but in open source it can go on forever as people work endlessly on different versions of the same software that nobody will use! That way you can be forced to have all of the different package managers installed (and keep them updated) so you can use the various software packages you might want to download!

Re:Sounds neat

nice try... apt works with RPM. The comparison is rpm <-> dpkg, not rpm <-> apt. In the correct comparison, they're almost equivalent.

Re:Sounds neat

Right, and furthermore it's not RPM that's playing catch up to DEB it's the quality of the available packages, and the standardization of versioning. Too many people make RPMs and assume that beacuse it's an RPM it'll work with any version of any RPM based distribution. This causes huge problems when figuring out dependancies.

The key is to get your packages from one source, where all the binaries are built relative to the other packages in the repository so that the dependancy names and versions are uniform throughout your system. This is what debian does better then everyone else. It has nothing to do with the DEB format, and it has nothing to do with apt either.

Re:Sounds neat

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:the essential question:

The question should actually be, "Why switch from .pkg?" (The .app extension is an application bundle, while .pkg is an installer archive.)

The answer is that if this standard package format were usable under Mac OS X as well, then it would increase the number of platforms a developer could distribute packages for using the same package system. Making that part easier for developers means Mac OS X users might get more software packages in an easy-to-use installer archive format rather than extracting from .tar.gz files (thus meaning the user doesn't have to be technically competent to install the program).