The Open Source software project OpenPKG has established the OpenPKG
Foundation, a nonprofit organization providing the ideational, financial, material and manned support of OpenPKG. OpenPKG is an “instrument for deployment and maintenance of Open Source Unix software when administration crosses platform boundaries.”
How does this differ from other cross-platform packaging efforts, like NetBSD’s pkgsrc?
How does this differ from other cross-platform packaging efforts, like NetBSD’s pkgsrc?
It differs in that it’s based on RPMs, you can use apt4rpm with it which brings the convenience of apt-get, and since it’s based on RPMs it takes little or no modification to use many of the existing software packages already available thanks to the popularity of RedHat, SuSE and other RPM based distributions.
OpenPKG allows easy management of both binary and source packages, binar management being something that things like NetBSD’s pkgsrc don’t do as well from what I know.
OpenPKG allows easy management of both binary and source packages, binar management being something that things like NetBSD’s pkgsrc don’t do as well from what I know.
It does that very well. Much better than FreeBSD’s ports for example.
It differs in that it’s based on RPMs, you can use apt4rpm with it which brings the convenience of apt-get, and since it’s based on RPMs it takes little or no modification to use many of the existing software packages already available thanks to the popularity of RedHat, SuSE and other RPM based distributions.
I don’t really understand that statement, especially in the light of portability. The binary package format has little to do with how portable a piece of software is, let alone the fact that RedHat RPM spec files are usually different from their counterpart in SuSE and friends.
On another subject, it would be interesting to know how OpenPKG deals with hidden dependencies and build options, which are the area where pkgsrc shines.
Quentin Garnier.
It does that very well. Much better than FreeBSD’s ports for example.
Oh? Does it require that you have create two seperate package specifications to have a binary and a source package that will reproduce the binary? If so, then it isn’t as nice as OpenPKG.
At last check, pkgsrc, and other systems like it (including Gentoo’s portage) required that binary installable packages have one ebuild, and then the normal one that build from source a seperate ebuild for example.
@Quentin
I don’t really understand that statement, especially in the light of portability. The binary package format has little to do with how portable a piece of software is, let alone the fact that RedHat RPM spec files are usually different from their counterpart in SuSE and friends.
And I don’t understand your statement in relevance to mine. The point of OpenPKG is to be able to create and maintain a specific set of software that is installe and works across multiple *nix environments. In this case, the OpenPKG project maintains packages that are binary installable across multiple Linux distributions and will work across them. Since OpenPKG implements RPM functionality internally, the differences between platforms is irrelevant to it. OpenPKG is a portable tool that implements RPM functionality and uses a seperate pacakage databse of it’s own. It does not affect the base system in any meaningful way.
For example, OpenPKG is so portable that I can create RPM packages that are buildable on both Linux and Solaris machines. Obviously the resulting binary package can’t be installed on Solaris and work, but I can use the same source package for both.
Oh? Does it require that you have create two seperate package specifications to have a binary and a source package that will reproduce the binary? If so, then it isn’t as nice as OpenPKG.
At last check, pkgsrc, and other systems like it (including Gentoo’s portage) required that binary installable packages have one ebuild, and then the normal one that build from source a seperate ebuild for example.
pkgsrc doesn’t have “source packages” like RPM has. With pkgsrc, you build the binary packages from a Makefile-based directory tree containing info on how to fetch/patch/configure/build/install the various software packages. Using this system, you can create binary packages (.tgz format), which can be installed on another system on its own right (provided it has the pkg_* tools installed, of course).
For example, OpenPKG is so portable that I can create RPM packages that are buildable on both Linux and Solaris machines. Obviously the resulting binary package can’t be installed on Solaris and work, but I can use the same source package for both.
Well, that’s the least you would expect from a portable package collection. I mean, you wouldn’t call it portable if it didn’t work that way.
Now what about choosing between built-in (i.e. already installed) software or the packaged version? What about making sure that you don’t silently depend on something built-in? What about choosing which dependencies you want for a package? What about choosing which compiler you want to use?
Quentin Garnier.
@Quentin
Now what about choosing between built-in (i.e. already installed) software or the packaged version? What about making sure that you don’t silently depend on something built-in? What about choosing which dependencies you want for a package? What about choosing which compiler you want to use?
As I already mentioned OpenPKG operates as a completely isolated package framework. This means that it is impossible to develop dependencies on built-in packages as OpenPKG works from it’s own package database. Choosing which dependencies you want at this time requires editing the .spec file for the package, but this is trivially easy to do. Choosing the compiler is as simple as setting the appropraite variable in the OpenPKG home directory .rpmrc file.
In a controlled software environment, there is almost never a need to change which dependencies or options a program is compiled with more than once during the initial source package creation. So I don’t find this to be a problem at all. Only users who want individually customized systems would go to the trouble of messing with changing configure options for a package. It’s a bad practice to get into when mass deploying.
Every system has it’s niche, some people will be better suited to pkgsrc, others to OpenPKG. In my case, the company I work for would only permit me to move to a different operating system if we could retain the use to do mass binary rollouts via apt-get and the use RPMs as the developers already know how to write RPMs.
Tried and it works.