The OpenPKG project released version 1.2 of their unique RPM-based cross-platform Unix software packaging facility. OpenPKG 1.2 provides 361 selected packages which include proven versions of popular Unix software — all carefully packaged for easy deployment on the six officially supported Unix platforms FreeBSD 4.7 and 5.0, Debian GNU/Linux 2.2 and 3.0, and Sun Solaris 8
and 9. Highlights in this version are a new approach for package build-time option handling, a fully reorganized and extended packaging of the Perl 5.8 language, and the availability of a new utility package “openpkg-tool” which
allows automated updating of whole OpenPKG instances with complex dependencies and used build-time options.
Cross-Platform Packaging Facility OpenPKG 1.2 Released
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Why would you created OpenPKG for Debian when the apt-get system is great, and has more packages. I think RedHat would definitely benefit more from this system than Debian.
Why not??
The whole point of this packager is to create binaries and have a common format for distribution. So, if you are a Solaris software company and you want to create packages of your software for many other unices, you might want to consider openpkg, just because it works on so many unices. You don’t have to mess up with RPMs, apt-get or whatever else.
You are thinking the whole thing from the wrong viewpoint. You are thinking about it as a Debian developer who might want to deliver his software for many other unices, so he might use openpkg for the others, but use apt-get for his debian. While you should mostly consider it if you are not a Debian dev, if you are an IRIX or a Solaris dev, and you just need a common packager.
You seem to be comfused between a packaging system and a package distribution system.
RPM,DEB,TARDIST,PKG,OpenPKG,… are all packing formats
URPMI,APT-GET,APT-RPM,… are package distribution systems
Comparing APT-GET to OpenPKG is like comparing a car to the highway.
When people talk about “dependency hell”, it has to do with package distribution and not the packaging format. Nothing prevents anybody from providing all the dependencies within a single RPM for example. Anyone who has tried to install official IRIX software knows that you can also have “dependency hell”. The only reason URPMI, APT-GET and the like work so well is that the repository has been carefully prepared so that no external dependencies exists.
OpenPKG does not even attempt to solve the dependency problem, which probably can only be solved by distributing monolithic software — a concept that is not compatible with unix tradition.
As pointed out by Eugenia OpenPKG and APT are designed for entirely different purposes. In fact each part mentioned has seperate purposes, which I will briefly compare for everyone.
APT is a frontend to the dpkg software package manager in debian and a rare few other distributions. Dpkg is the underlying application that manages .deb files for Debian based systems.
‘Deb’ files are simply the chosen storage format for packages in the Debian archive. According to many reports it is very similar in structure to RPM.
‘.rpm’ is also a storage format for software. It is used by a vast number of distributions and is considered standard package format by the LSB. (Man this really irked the Debian croud.)
Rpm is also the name for the standard package manager in Redhat and is used in the same manner as dpkg above.
IIRC, Mandrake was clever enough to create APT-rpm which functions as a frontend to rpm and provides much of the functionality available in the original APT.
Both APTs are used as a method of resolving dependancy and retrieval matters. Thus the slogan “Debian, APT-get into it.”
OpenPKG appears to be a source package distibution method. All the above tools are often used on binary packages. (We will briefly skip the apt-source tool.) Source packages are necessary because build time options for available unices can vary greatly. In fact these options can vary greatly within a single unix. (Read architecture specific stuff)
Presumably a software developer seeking maximum portability can use OpenPKG as a format/method of distibuting testing/final versions of software. This is especially important to groups that do not have the manpower to provide a packager for each package system.
Sadly there is no real gaurentee that this will work effectively or pick up in usage. Without a groundswell of support it will probably end up overlooked.
As an avid Debian user I don’t have much for this, but I can see it usefullness to projects like Mozilla and Apache. Any equally large project may need as much distibution and testing as possible. OpenPKG would make it easier to deliver the software.
In the end use the tool that fits your needs. Your choice.
I like the BSD ports system the best (e.g. for FreeBSD). I use it to build things from source, and there is no “dependency hell” because it builds the dependencies, recursively, first. It’s nice because inside the small “port” package are directions for fetching the source, and building the package. Inside the ports database all the dependencies are defined, and the ports system will fetch and build the dependencies too. You can install something big like gnome with one command.
There is also a system-wide make setup in BSD, so your debugger/optimization settings can be set the same for everything, e.g. you can give the “-mcpu=pentium3” option to gcc for all that you build. Thus all that you install can be optimized for your system.
In a sense this is a package distribution system without packages, since you build everything.
My favorite binary package system is the one used in Solaris.
Dependencies never bothered me much, because it can be fun to go get them and learn about the other projects which the app. you’re installing was built on. For example, if you set up gnome without using a popular “meta-package” you will browse through many other cool projects which it depends on, and learn more about the imagination and creativity of the worldwide community of programmers.
Why would anyone use this new packaging system, while Solaris has an advanced packaging system that works perfectly well already? The Solaris software packaging and management system is an order of magnitude more functional than RPM.
Cross platform as long as it’s Unix? That’s just like saying cross platform as long as it’s Windows.