Slashdot Mirror
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.
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?
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.
Leandro Guimarães Faria Corcete DUTRA
DA, DBA, SysAdmin, Data Modeller
GNU Project, Debian GNU/Lin
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?
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!
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.
"Oh, I hope he doesn't give us halyatchkies," said Heinrich.
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!
They are pushing the use of source packages,
that would need to be compiled, hence, they can
adapt to each platform. They only advocated
the use of binary packahges when the developement
tools ( mainly gcc, automake ) are not available.
It's basically an RPM based FreeBSD ports tree.
Novel idea.. but am not sure the use of RPM
is the best choice...
We shall see..
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.
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*
Hmmm, I'm a little skeptical of this theory. The first Red Hat "Mother's Day" release was in 1995. It didn't include RPM, but did include its ancestor rpp. The first releases of Debian which included the primative version of dpkg were around the same time. I don't think one was significantly before the other -- they were basically in infancy together. dpkg certainly didn't seem more "baked" than rpm at the time.
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?
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. (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 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.
I print, therefore I am.
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?
Or, even more amazingly...
$ rpm -ta yourSourceThatAmazinglyHasASpec.tar.gz
RPM does nothing to keep a system administrator from customizing their own packages, assuming they sit down for five minutes and learn how to modify a specfile. All it does is allow you another level of control over the files (and their dependencies... and integrity) on a system.
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?
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.
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.
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.
gopher://cramer.plaintext.cc http://cramer.plaintext.cc:70
Congratulations, you just described the FreeBSD ports system.
Expanding a vast wasteland since 1996.
They are pushing the use of source packages,
that would need to be compiled, hence, they can
adapt to each platform. They only advocated
the use of binary packahges when the developement
tools ( mainly gcc, automake ) are not available.
It's basically an RPM based FreeBSD ports tree.
Novel idea.. but am not sure the use of RPM
is the best choice...
We shall see...
Mind you, using the RPM system is pretty self-defeating too.
TWW
"Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"
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.
.deb, and if someone was going to switch from RPM, why not switch TO deb and have a huge base of packages and tons of mirrors to choose from?
Choice is good, yes, but there comes a point where you have to realize that choice that creates incompatibilities is not really choice at all.
RedHat is still going to use RPMs, they won't switch to the new format. Neither will Debian. FreeBSD has ports already, and frankly, it's probably better than this option. OS X has apt, ports, AND its own package format, plus purchasable software.
Why do we need another option just to have another option? The only way to make it truly universal is to make it source, and that basically gives you FBSD.
Sure, maybe i'm totally wrong about what this new package system is like, but I don't really care. It's more confusion thrown into the mix, and yet another package format for people to support. It's not worth it. If people are going to duplicate effort, why can' they write software people will use and care about?
There's no reason for anyone to switch from
--Dan
You're comparing apples and oranges, my anonymous, not-too-bright child. RPMs are packages. Debian's package management system is, well, a package management system.
I used to use RPMs all the time but since switching to Debian it's SOOOO much easier to get and upgrade packages.
Still apples and oranges. Truth be told, the RPM format is more robust than
Stating on Slashdot that I like cheese since 1997.
Gentoo Linux (http://www.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.
Stating on Slashdot that I like cheese since 1997.
Even better, apt-get has had RPM support for quite some time.
Stating on Slashdot that I like cheese since 1997.
You don't necessarily have to package anything to get dpkg to know about it. Simply use the "equivs" program: % apt-cache show equivs
...
.
... /usr/local, and use equivs to generate a fake deb telling the packaging system the foo library is installed, and thus all your dependencies will work.
Package: equivs
Description: Circumventing Debian package dependencies
This is a dummy package which can be used to create Debian
packages, which only contain dependency information.
This way, you can make the Debian package management
system believe that equivalents to packages on which other
packages do depend on are actually installed.
Thus, you can build something from source, install it in
On that note, though, I honestly prefer having dpkg and apt-get control all the software installed on my Debian systems. Binary package availibility in the "sid" distribution (or "unstable") is usually only a day or two behind releases of actual source. And for those who fear breakages in sid (which does happen from time to time), there is always the "testing" distribution of Debian, which does not include packages known to be bad by implementing a short waiting period and checking bug tracking systems -- and almost never breaks.
cross-platform RPM-based Unix software packaging.
crossplatform:
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.
Red Hat Packaging Method version 3 (the latest of which is 3.05) is the Linux Standard Base packaging system and has been some time now.
Debian supports the LSB in this manner via APT - I think that's a nasty solution, and will cause more long term plain tham implementing things like suggested dependencies (and different levels of suggestion), and some other minor things.
Issues like policy, task packages, and APT are already a reality on many RPM based Linux distributions, so I don't see the technical difference between them really being that great.
Of course, that won't stop the people who haven't used one or other system from complaining below that one or the other system doesn't do things it clearly has for a very long time.