OpenPKG 1.0 Released 222
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."
Re:Yet another package management system? (Score:2, Insightful)
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:hmm... (Score:3, Insightful)
Different systems have different requirements in packages. At a minimum
The only thing I can see being good about it is on systems where you don't have a vendor supported pacakging system as good as RPM. But, if it's purely for functionality, why not just port apt?
Re:Time loss (Score:5, Insightful)
Re:Congratulations Ralf. (Score:4, Insightful)
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.
Re:hmm... (Score:5, Insightful)
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.
Duplication of Effort is *Okay* (Score:5, Insightful)
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.
Re:Time loss (Score:4, Insightful)
My point is that
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.
RPM's (Score:2, Insightful)
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?
Re:Time loss (Score:4, Insightful)
Too little, too late (Score:1, Insightful)
I'll never tourch RPM again if I have too (Score:5, Insightful)
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? (Score:5, Insightful)
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?
Re:RPM?!?!? (Score:2, Insightful)
$ 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.
Cross-platform? (Score:3, Insightful)
To me, true cross-platformness includes the ability to run on AS/400s, S/390s and VMS. Like emacs or slickedit or... perl?
John.
Re:Sounds neat (Score:5, Insightful)
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:Congratulations Ralf. (Score:2, Insightful)
Every production and testing system I work with has no compiler, because we build software on development systems. The compilation and the installation are separate functions.
There's no reason to install software you don't need, and you don't need a compiler to install a software package.
One reason not to compile your software everywhere you want to install it is because when you test the software and find that it works on your system, you don't want to invalidate that test by installing a different build of the software on subsequent systems.
Re:Congratulations Ralf. (Score:2, Insightful)
When I went to secure my home web server, I removed the various compiler(s) that had been installed by default. And make. And the various editors. Every shell except bash. All client software - ftp, ssh, telnet, finger.
In short, I removed everything except what was absolutely needed on the box. I have SSH set up so I can connect to the box remotely, but anything else - including file transfers - happens via floppy or CD.
I know there must be a way for a determined attacker to get wahtever software they want onto the system if it's ever compromised. I'm betting that:
(a) the majority of attackers will be l33t script kiddies who lack the skill to compromise the system in the first place, and
(b) anyone who has the time, skill, and energy to do so will probably be off rumaging through an interesting system somewhere else, not my dinky little P133 webserver.
Re:I'll never tourch RPM again if I have too (Score:3, Insightful)
Same thing with Debian: small number of groups creating packages, therefor the dependancies are well maintained.
Now, RPM is used by a very LARGE number of groups, many of whom are not even aware of each other's existance. Furthur, some of those groups are very sloppy about the dependancy data they add to their packages (my favorite: I want version 1.2.3-pl5-v4-x_i686_mmx_with_asm_x-thursday-4_31_
The problem is NOT in the package format, it is in the absense of any centralized agency performing QC on the builds.
Re:Cross-platform? (Score:2, Insightful)
"all flavors of Unix" - many competing vendors
There is a difference.
And "cross-platform" != "universal"
Does slickedit run on CP/M? AmigaDOS?