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."
Let's just say that Ralf is the commited guy for standard packages.
http://www.openssl.org/
http://www.modssl.org/
To say a few.
He's the guy that wrote mod_rewrite back in the old days. Tough guy.
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.
Will I retire or break 10K?
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.
I don't even know how to begin replying to this, but i will give it a try ;-)
.spec file). This 'source package' you can then compile on each different architecture and platform.
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
(resulting in a binary usable for only that platform).
This makes cross-platform/architecture distribution a lot easier, and a lot easier to maintain.
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.
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.
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?
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?
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.
Congratulations, you just described the FreeBSD ports system.
Expanding a vast wasteland since 1996.