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."

Comments

COOL!

[Sobrique]

How very useful.
Whilst Solaris does have package management, it's not as good as RPM.
Of course, now all you have to do is convince sun to support it :)

Re:COOL!

[-douggy]

No we have to convince everybody to use it.
Nobody like having to find specific versions for their systems. (unless you're source junkies)

Re:COOL!

[rse]

No, .tar.{gz,bz2} ever was and ever will be a Unix developer's distribution format. OpenPKG is for system administrators of large imhomogenous networks, but when I have my developer's hat on I do not care about RPMs at all. OpenPKG is just one of many packaging facilities -- although my preffered one. But that doesn't count when I release Open Source software.

Re:COOL!

[Enahs]

RPMs aren't as good as Debian's package management system though.

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 .deb, and to tell you the truth, our (yes, I use Debian . . . for the moment :-) precious apt system wasn't designed for just deb. Conectiva and Mandrake (their Cooker, the equivalent of Sid), among others, are both apt-enabled and RPM-based.

Congratulations Ralf.

[bodin]

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.

Re:Congratulations Ralf.

[Anonymous Coward]

Yes, and he should be very pround :-)

Re:Congratulations Ralf.

[ichimunki]

While I appreciate this work, what I really don't understand is why not work on building a tool that doesn't rely on "packages" so much as it relies on source tarballs that are independent of any packaging system.

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:Congratulations Ralf.

[Tet]

Then the system takes the package and builds/installs it using a user account set aside for the purpose of installing non-base software.

Bah! Why is it that no one suggesting these sorts of things has any operational experience? The chances are that the machine on which you're installing the package doesn't have a C compiler, which tends to make your plans to build from source a little unworkable. The usual answer is people telling me that gcc is available for pretty much every system these days, and that I should just install that. No one seems to have the concept of installing the minimum necessary to get the job done any more, something that's particularly important on public facing (and hence higher security risk) boxen. Sigh.

Re:Congratulations Ralf.

[JahToasted]

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.

I had this idea myself at one time. Mostly because I think that I have a good name. I figured that windows had wizards to install things, So Linux should have a "Sourcerer". Well maybe you don't find that to be as an amusing pun as I did, but I wish you lots of luck in your project.

I recall that the guy who started KDE (what's name again?) once mentioned working on something like this.

I would be interested in help you out on this. I think that my best skill is in designing User Interface, but I can programme as well. If you need some help send me an email...

Re:Congratulations Ralf.

[ichimunki]

A Unix machine without a C compiler? Can you name a few popular systems that have this problem?

And can you tell me what the odds of this package system being useful to people on those platforms actually are? I don't know if you've ever worked on a non-x86 platform, but try finding even very popular software packages pre-compiled into *either* RPM or .deb packages with any degree of currency and you'll know what I'm talking about. I cannot count the number of times I would've installed a proprietary package on my Yellow Dog system, or some other complex package that I was not anxious to spend three days compiling just to try it out, but couldn't/wouldn't because no precompiled PPC packages existed or were only from sources I had no reason to trust.

Re:Congratulations Ralf.

[TilJ]

> A Unix machine without a C compiler? Can you name a few popular systems that have this problem?

My OpenBSD firewall. No use locking a system down if a user can build their own tools ...

I needed to add snort to the firewall and binary packages made that painless.

Re:Congratulations Ralf.

[ichimunki]

Ok. But everyone and their mother can get a C compiler for OpenBSD without blinking twice. You are not accounting for the situation where you rely on precompiled binaries, but don't have a trustable source for them (or any source in some cases). In your situation, you *could* easily get by without precompiled binaries by compiling the package on one of your other systems, and copying the executables, libraries and */share files to your firewall.

Frankly, I don't see how taking the compiler off the firewall enhances it's security. If I have access to run the compiler, I probably have enough access to simply copy precompiled binaries over. In fact, that's what you were doing when you installed snort. And if I were cracking a box, I think the last thing I'd want to do is run something highly noticeable, like a compile process.

Re:Congratulations Ralf.

[Tet]

A Unix machine without a C compiler? Can you name a few popular systems that have this problem?

Every single one of the production systems for which I'm responsible (currently Linux/x86, Linux/SPARC, Solaris/SPARC, Tru64, AIX and OpenBSD). If you'd read my original message, you'd see that the lack of a C compiler was through choice, not lack of availability.

couldn't/wouldn't because no precompiled PPC packages existed or were only from sources I had no reason to trust.

That problem wouldn't be solved by a package management system that compiled from source. A source package from an untrusted location is just as bad as a precompiled binary from the same location.

Re:Congratulations Ralf.

[dshelt]

Solaris doesnt ship with a c compiler anymore. You either buy Suns' Forte C Compiler or dload a precompiled version of gcc and use it. IIRC AIX doesnt ship with a compiler either, you must buy a compiler from IBM or get a binary of gcc.

Re:Congratulations Ralf.

[JLouder]

A Unix machine without a C compiler? Can you name a few popular systems that have this problem?

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.

[shoor]

Well, I for one think Sourceror is a pretty cool
name.

Good luck.

As for Ralf's project, being a slackware guy,
I am kind of interested in finding easier ways
to get all them rpm packages installed, maybe
this'll help.

Re:Congratulations Ralf.

[Samrobb]

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:Congratulations Ralf.

[Jeremiah Cornelius]

Properly configured firewalls, bastion hosts and ANY DMZ box have no compiler, and should have no client facility to pull data from anywhere - except for designated, trusted hosts on separate INTERNAL segments. This is enforced by firewall rules and router ACLs.

The firewall and IDS hosts must be so hard that no browser or FTP/rsync client etc. is installed at all. Upgrades, rules and signatures are tranfered to these systems only by valid, encrypted and keyed clients from appropriate stations- for instance the GUI for Checkpoint Firewall-1 with FWZ. ssh2/scp2 is also acceptable, when RSA key auth is employed (NO passwd!) along with rules and ACLs.

This is a part of "Defense in Depth" practice for Internet hosting.
These defense approaches begin to separate the objectives of Security distinctly from those of Systems administration. This can be counter-intuitive because short-term administrative convenience is reduced to reduce the risks of administrative catastrophe.

I am a little extreme but -provided that my controls are themselves trustworthy- I can provide an extremely hard target!

Of course there are people who can construct exploit tools with sh, awk and dd. It is for these malevolent masterminds that we deploy detective controls!

Re:Congratulations Ralf.

[xsbellx]

Well how about AIX for one. Since version 4.0 of AIX, IBM has NOT include a "C" compiler as part of the base operating system. I agree, it can be purchased or GCC can be installed but both of these have negative implications in a corporate environment.

Purchasing a C compiler costs money and bean counters and the like object to anything that adds to the cost of a box. Using GCC, or for that matter, any software that is not supported by a vendor, is usually strictly forbidden.

This policy or a similar type varient, has been the standard at almost ALL of my employers (3 fulltime and 14 contract over the past 22 years). On the other hand, development boxes are usually not quite as vigilantly monitored.

I am not saying this good or bad just passing along some anecdotal evidence that:
if (sys == Unix) {
C compiler == TRUE
}
is no where near as true now as it once was.

Re:Congratulations Ralf.

[tricorn]

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.

You can always tell it to ignore dependencies. You might have problems if install scripts require something you don't already have, but then you said you know you have it, so it shouldn't be a problem. The dependency problem for installing things from source can be much worse, and version requirements can be much trickier (most pre-compiled packages only have dependencies on library versions, and those are easier to satisfy than some of the wacky dependencies some source packages have).

Many, many source packages use GNU autoconf/automake/autoheader/etc, Wall's Configure, imake, cook, and so on. Those seem to meet your desire to have something that will help you write a "shareable makefile of sorts". Adding a layer of "fetch things I don't have" using a variety of methods is fairly simple, but the dependency problem still comes back to bite you.

RPM source packages are very much like what you're asking for as well. One problem it solves is that original "pristine" sources are separated from whatever patches were necessary (to source, scripts, Makefiles, whatever) to get it to compile in the same environment as the build is intended for (I'm not saying source RPMs are the only ones that do that, of course). The main problem I ran into with them was that they didn't have any dependencies on what was required to BUILD them, but I haven't kept up with the latest versions, so maybe even that has improved.

Keeping a database of what is installed, what files belong to which, what files are going to have conflicts between packages, what steps are necessary to uninstall a package, what files are user-configurable files and should be saved, etc. is very useful. Even if installing things from source, I'd want something to help keep track of everything.

BTW, a bootstrap "full build" binary is on the order of about 18MB and 120 files. That's enough to re-build itself and any other package (although you'll still have plenty of packages that need other packages built first - I suppose I should see how deep the dependency chain gets when trying to build, say, GNOME or KDE!)

Re:Congratulations Ralf.

[ichimunki]

Except that usually source packages can be gotten from a trusted source (i.e. the developer or an authorized/official mirror).

Re:Congratulations Ralf.

[ahde]

do you know how long it would take FreeBSD to install if it had to compile everything? And do you know how hard it is to bootstrap a system into compiling its compiler, etc?

Re:Congratulations Ralf.

[FattMattP]

A Unix machine without a C compiler? Can you name a few popular systems that have this problem?

Sure. None of the SGI machines that I have purchased or used came with C compilers, or any compilers of any sort. For the ones that did need compilers, we had to purchase it from SGI.

Re:Congratulations Ralf.

[Samrobb]

Interesting. I consider the risk minimal, though. Someone would first have to gain access to the box, then either guess or crack a password to gain access to the box via ssh. They can't transfer files off the box, and they can't get software onto the box, which makes getting that password much more difficult. Overall, I think the worst case scenario is someone gaining access, seeing that there's no easy way to do anything, and doing an rm -Rf. Even with that, I'd loose nothing of any real importance - my personal site is small, and well indexed :-) I've actually managed to entirely rebuild it (except for images) from Google's cache once.

hmm...

[reaper20]

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?

Re:hmm...

[datajack]

I very much doubt it.
Different systems have different requirements in packages. At a minimum

• Processor & architecture for binaries
• Filesystem layout
• Configuration requirements for related software (not everywhere, for instance uses the same inetd.conf format)
• Dependancies on libraries
• Naming conventions for packages
• etc..etc..etc..

I hate to be a pessimist (OK, that's probably a lie ;) but, as you would still need individual packages for almost every platform, I don't see what the big deal about this is?
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:hmm...

[chabotc]

I don't even know how to begin replying to this, but i will give it a try ;-)

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 .spec file). This 'source package' you can then compile on each different architecture and platform.
(resulting in a binary usable for only that platform).

This makes cross-platform/architecture distribution a lot easier, and a lot easier to maintain.

Re:hmm...

[TheFalken]

> as good as RPM
:lol !
Have you seen apt ?

Re:hmm...

[Anonymous Coward]

A someone else has said, the intent is that the source code will be there, therefore allowing use of automake et al in the build process.

Doable.

Lets hope that there is sufficient take up to allow proper dependencies to be included and found.

Re:hmm...

[TheFalken]

Apt has stuff built in that rpm, imho, needs.

Re:hmm...

[Enahs]

urpmi has stuff built in that dpkg, imho, needs.

get it? no? ask someone who knows.

Time loss

[leandrod]

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.

Re:Time loss

[GauteL]

This is not very relevant anymore. Almost all distributions and projects have chosen RPM, and there really isn't much point in remaking the decision.

Besides apt already exists for RPM, and works fine. Since my favourite mirror got APT-enabled I've used it almost exclusively.

I would like to start seeing *.lsb.rpm soon, guaranteed to work on all lsb-compliant distributions. As long as they are competently created they should be debianizable through alien .

Re:Time loss

[TheFalken]

I agree, from the OpenPKG web site:
"If the build or install process depends on other packages, OpenPKG will tell you about these dependencies and halt the process until you resolve the dependencies installing related OpenPKG packages. "

So it doesn't automagicly resolve problems, like apt-get does, which is why, having used both, I prefer apt-get.

What happened to the effort ot combine rpm and apt ?

Re:Time loss

[mjh]

I would like to start seeing *.lsb.rpm soon, guaranteed to work on all lsb-compliant distributions. As long as they are competently created they should be debianizable through alien.

Amen, brother! Score:+1,Insightful (virtual moderator point for you!)

Re:Time loss

[Captain Morgan]

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.

Re:Time loss

[CatherineCornelius]

Why not just port and use dkpg, apt and associated tools? They were all created to be portable, and are indeed already used in fink./, debian-cygwin./ and the like.

Those are both very interesting projects. Since the superiority of deb format is universally acknowledged, I'm surprised that anybody would consider its dumber sister. Debian distribution is famous as the one that you can upgrade to the next version just by typing "apt-get dist-upgrade". That's very powerful package management. Add to this the huge number of software packages that have already been Debian format and are being actively maintained by Debian package maintainers who seem to be only too keen to share their knowledge of the format...

Re:Time loss

[LizardKing]

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

RPM wasn't a duplication of effort, more of a parallel development. This happened quite frequently in Linux world of the mid nineties - anyone remember the alternatives to the ext2 filesystem (I can't even remember their names now)? We still see it with the proliferation of journaling filesystems.

To see it as some anti-Debian conspiracy is to exhibit unfounded paranoia. The Debian project works to its own agenda, and a pace that some find exasperating, so please don't start anti-RedHat FUD on the basis of that.

As for the merit of porting dpkg, etc. - why would you need to? They already run on most architectures, it just comes down to a choice of distribution. *Personally* I prefer RPM because it handles dependencies and versions in a much more sophisticated manner than debs do. This was borne out of a tedious discussion on my local LUG mailing list, where a Debian contributor bad mouthed RedHat and RPM in particular, and was promptly made to look a fool.

Re:Time loss

[GauteL]

Why should be judge them on technical merit? Both are perfectly adequate, and even though .deb may be technically better, the main reason for people disliking rpm is the amount of incompetently built rpms available.

My point is that .deb may be marginally better technically, but it doesn't matter as long as most projects have chosen .rpm, and the cost of remaking that decision is FAR bigger than any advantages.

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.

Re:Time loss

[mattdm]

I'm not even sure .deb is technically better. There's some things RPM does nicely that dpkg doesn't. (For example, the "one big patch" idea in dpkg means that if you're going to add patches of your own to an upstream package, you need to invent your own structure for keeping your changes distinct, and reinvent it for each package, as far as I can tell. RPM deals with lots of patches nicely, and I think it's one of the reasons that there are so many Red Hat-derived distributions.)

Re:Time loss

[ink]

So it doesn't automagicly resolve problems, like apt-get does, which is why, having used both, I prefer apt-get.

For the (hopefully) last time: APT HAS NOTHING TO DO WITH THE PACKAGING SYSTEM other than requiring the package system to know about dependencies. APT works just fine with RPM, just as it works fine with debs and I see no reason why it couldn't work with OpenPKG.

Re:Time loss

[JonKatzIsAnIdiot]

You Debian guys are starting to sound like the Mac users of the Linux world.

Re:Time loss

[Ranger Rick]

That's not a function of dpkg, though, it's a function of apt and Debian's very strict policies for the naming and interdependence of packages.

Functionally, dpkg and rpm are almost identical. The powerful part of Debian's system is the convenience of apt as a delivery mechanism, and the power of the human part of their package management. Not the actual binary packages themselves. The real power of Debian is here.

It seems like openpkg has used something similar to BSD ports as their delivery mechanism and used RPMs instead of .pkg's... Whether their packaging guidelines are good, however, is to be determined.

Re:Time loss

[Sosarian]

> Besides apt already exists for RPM, and works
> fine. Since my favourite mirror got APT-enabled
> I've used it almost exclusively.

Which mirror is that?

Or...is there a list of Redhat mirrors that are apt enabled now?

I know of freshrpms.net, but I don't know if they have a complete redhat installation on their site.

Re:Time loss

[GauteL]

I use ftp.uninett.no.. I'm norwegian.

Seems to be only two mirrors so far, listed here:
http://apt-rpm.tuxfamily.org

Re:Time loss

[dirty]

Please explain to me what makes debs better than rpms. Don't tell me that apt is a better tool because AFAIK that has nothing to do with the package format, just the program used to install it. From what I understand RPM 3.0 (the package not the proggie) has all the necisarry info to be able to grab dependencies for you.

Re:Time loss

[Jeremiah Cornelius]

Which mirror is apt-enabled? My main resistance to rpm-apt has been the dearth of packages for RedHat boxes I run.

Do you run Connectiva or Mandrake?

Re:Time loss

[fenux]

you're right, there is no point in advocating that everybody should switch to debs, just like there is no need to start advocating that microsoft is evil.. lets all keep using good old ms, and if something is good lets just shut up about it, because the old way ain't broken(or not that much). Hell, as much as i heat advocting things as you put it, whitout it, nothing would change, because noone would hear about the new and better alternatives...

debs are the best, and don't let anyone tell you otherwise :)

Re:Time loss

[TheFalken]

From the end user POV, it doesn't matter. DeadRat ships with rpm, debian with apt-get/dpkg using .debs.
rpm -Uvh is a pain for anthing remotly complex, apt-get install isn't.

Re:Time loss

[Enahs]

Of course there's areas where rpm is superior...just don't tell the Debianites, as you'll have an apt jihad (and apt isn't even deb-specific! dpkg is the package manager!)

It's relevant to point out that it's possible to put together distributions with crappy dependencies using either rpm or deb.

Re:Time loss

[GauteL]

The problem is that your parallell doesn't work here. RPM is free software, Microsoft does not supply free software. Microsoft is a monopoly, Red Hat is not.

Besides. RPMs are not shoddy technology. It is a good technology, that works and is used by almost everyone in the Linux-arena. Please feel free to advocate, but you won't get anywhere, because there simply IS NO POINT in switching to debs. It will buy you almost nothing, at the expense of a lot of work.

Show me some evidence that switching to debs is worth all the effort, and I'll shut up.

Re:Time loss

[meridian]

You create changes yto the source package and make a change to the changel;og then create an updated source package using dpkg-source -b pkgname-dir-1.01 its quite simple when you realise whats to it. there is often a debian/patches/ dir to dump extra patches into as well, or if the is not it isnt hard to modify debian/rules to account for any patches. for me apt-get debian/rules

Re:Time loss

[leandrod]

Sure the RPM situation is far better than the Win32 one. But comparing to .NET, .NET at least was submitted to a standards body, which is not the case with RPM.

RPMs are not shoddy technology, I just used it as an example of an inferior technology taking the place of a superior one -- depending on your technical beliefs you could point other examples like Alphas against anything else, RISC against CISC, QUEL against SQL, RDBMS versus object orientation, functional versus OO, Lisp systems versus POSIX, POSIX versus Win32, or whatever.

BTW, if people switched to Debian -- even by using apt with RPM as a bridge to apt with dpkg -- users and sysadmins would be able to more easily compare the quality of the packages they get with Debian ones, to more easily adopt anv verify compliance to better system-wide distribution policies like Debian's before accepting packages from anyone... it would be far easier to package (just recompile and rebuild the packages) to every platform already supported by Debian.

Like POSIX versus Microsoft, it's not about a product like GNU/Linx versus another product like Windows; it's about cultural differences and their practical consequences.

Re:Time loss

[leandrod]

The issue is that with apt-rpm you don't get all the good policy decisions that are usually taken for granted in deb packages. The use of deb (or any common successor to both deb and rpm that is a superset of *both*) coupled with FHS may make it far easier to compare "common" packages floating everywhere, like vendors' ones, to high-quality Debian ones.

Re:Time loss

[leandrod]

No paranoia here, no anti-Debian conspiration -- it's just the usual way things go. There's something better that takes time to get right, someone takes a short cut that has bad consequences but gets to market first, so grabbing both market~ and mindshare.

The comparision to ext2fs actually works against RPM. In the Linux kernel problem space Linus gets to decide on the standard filesystem, he decides slowly and is conservative so to get technical excellence first. But he simply isn't interested in the distribution problem space.

Excuse me, RPM handles dependencies and version more sophisticadedly? Sure... but here comes Occam's razor: dpkg's way is much simples and get all the work done with less fuss and more efficiently. RPM has lots of short-sighted unnecessary complications built-in.

As for your local LUG mailing list, sorry, but local LUGs aren't any standard for technical excellence. Most people there never seen proper system administration, still think MySQL is really a RDBMS, SQL is the relational standard and don't grok functional languages.

Re:Time loss

[leandrod]

Macs as machines and architecture are still technically far superior to PCs. Silent, energy-efficient and beautiful. Pity it's a closed architecture, but so is the PC becoming.

Paralleling the Debian/Red Hat situation, PCs' only advantage is soon to became market~ and mindshare.

Re:Time loss

[leandrod]

Not a single distribution, but a set of best practice guidelines for packaging that is created for system administrators by hackers.

The issue with huge number of deb packages, it is true -- all of them created integrated with the same set of packaging and system administration policies in mind. Whereas the rpm format is actually fragmented into a very low lowest common denominator, or else duplicated for all the different inconsistent RPM distros.

Could you give us an URL for a good explanation *and* proposal for this .spec issue? I'm not familiar with it.

Re:Time loss

[leandrod]

It's not an end user decision, it's a hacker decision that was overriden by a corporation. And ill-informed system administrators -- "every user a system administrator", even if not educated enough that corroborated that.

As you noted, the user is left feeling the pain, no more than that.

Re:Time loss

[mattdm]

I don't think the "Red Hat is a company" argument applies in this case. It's certainly a factor in adaptation of the distro itself, I don't think the decisions re: starting derived distros are made by people at that level of thinking.

/usr/src/redhat/SOURCES is just a default location, and I agree, it's kind of ugly. It's a trivial change in your .rpmrc to make it put source files in a different location (for example, on a per-package basis) and that's what most RPM builders do.

It would be nice if there were a "patch up to patch #N" command line option", but I don't see that as a big hurdle -- it's not something I find myself wanting to do very often.

Re:Time loss

[LizardKing]

As for your local LUG mailing list, sorry, but local LUGs aren't any standard for technical excellence.

The Oxford (United Kingdom) list tends to have reasonably high level of cluefulness thanks to the Universities and number of tech companies hereabouts. The particular people involved in the RPM versus debs discussion, while not being big names in the Linux world, certainly have the bona-fides to know what they're talking about.

Re:Time loss

[Tet]

The Oxford (United Kingdom) list tends to have reasonably high level of cluefulness

Equally, the GLLUG (Greater London) list has a fair amount of technical knowledge. It's frequented by both kernel and gcc/glibc hackers. Plus all the other stuff you expect from a LUG list -- clueless newbies, flamefests, etc. All the things that make life interesting :-) But overall, it's a pretty sound group.

Re:Time loss

[leandrod]

OK, would you care to give the URL to the start of the discussion?

Anyway I judge mailing lists and newsgroups just as I judge newspapers, by their treatment of issues I know. Usually they are pretty weak on databases and system administration, instead focusing on the latest, fastest, and fadest. Usually they are as chronologically snobish as the rest of our culture, sposing OODBs, OO programming and Red Hat alike against the sounder RDBMS, functional programming and Debian.

Microsoft is moving to MSI

[yerricde]

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.

Re:Yet another package management system?

[Anonymous Coward]

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!

Re:Sounds neat

[Ranger Rick]

nice try... apt works with RPM. The comparison is rpm <-> dpkg, not rpm <-> apt. In the correct comparison, they're almost equivalent.

Re:Sounds neat

[arthurs_sidekick]

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.

Uses separate RPM repository, no NLS

[bojolais]

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!

Re:Uses separate RPM repository, no NLS

[ignavus]

they favor English ... And they're not even Americans!

There are 800 million English speaking people in the world (or something in that ballpark).

There are less than 300 million Americans.

Therefore, the majority of English-speaking people are not .... go on, try hard, you can work it out, it begins with an 'A'!

Re:Uses separate RPM repository, no NLS

[bojolais]

Many French speak English. When was the last time you heard a Frenchman say he preferred English?

In case you haven't heard of it, there is a joke stereotype of Americans being linguistically inflexible.

I appreciate your stats. Before your remark, I was completely convinced that the majority of English-speakers were Austrialian. Or was it Austrian?

Oh, and in case you weren't aware, Americans don't speak English. We speak American.

Why RPM ?

[mjander]

It really surprises me that they decided to use RPM package format. It surprised me even more that they decided to create "Yet another package system", while there are many very stable and advanced one, that are just waiting to being ported to "Yet another Unix".

My personal experience is
RPM = headache.
APT = a lot of relieve.

mjander.

Re:Why RPM ?

[Raleel]

apt has been ported to rpm. This was not a valid comparison then (a package format vs an installation system), and it still is not.

Re:Why RPM ?

[Enahs]

Even better, apt-get has had RPM support for quite some time.

Not Exactly....

[keepper]

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..

Duplication of Effort is *Okay*

[Sargent1]

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.

Re:Duplication of Effort is *Okay*

[oldmanmtn]

Sometimes it's OK, but usually it's not. When it comes to packaging systems, it's downright stupid.

Packaging systems solve two problems: software distribution and dependency tracking.

In order for a packaging system to handle the distribution aspect, both the packager and end user must use the same packaging system. If you package your software with dpkg and I only have RPM on my system, then you have failed to distribute your software to me. That problem is solved easily enough: every user must have every packaging system installed. It's a pointless waste of space, but what the hell; disks are cheap.

The more serious problem is resolving dependencies. You distribute your gnome app using dpkg, but I've installed gnome using RPMs. How do we validate that I have the correct version of gnome (or any version for that matter) in this case? Sure, if I know that I have the right version installed I can tell the installer not to worry about the check, but then I've lost any benefit of the packaging system in the first place.

I know this "it's OK to reimplement the same thing over and over again - that's the beauty of OSS" mantra is widely accepted as gospel on Slashdot, but I'm just not buying it. What's the point of having 100 half-assed projects all failing to do exactly the same thing?

Just as an example: go to sourceforge and look at desktop_environment:window_managers. There are 102 entries! (yes, I know a lot of those aren't really window managers. That list includes themes, menu converters, etc. That's not the point.) Most of them claim to have the same goals: lightweight, flexible, fast, configurable. And most of them are crap. There are hundreds of text editors on sourceforge; 95% of which will never be used by more than 5 people. What a freakin' waste of human effort.

The true benefit of Open Source should be that it frees us from having to solve the exact same problems over and over and over. It should enable us to go out and do new things and solve new problems. If you want to write TextEditor #1342 as a way to learn a new language, then more power to you. But don't try to tell me that the world is a better place because somebody has decided to slap together yet another "powerful programmer's text editor" and put it on a web site.

Re:Duplication of Effort is *Okay*

[alext]

Perhaps one of the moderators perceiving such insight in the above would like to share with the rest of us his method of avoiding forced duplication of effort in all code depending on such duplicated functionality.

For example, the Java SWT library is currently being ported to Motif and GTK+, those of us using KDE are out of luck until yet more resources can be found for what on Windows is a single task.

Re:Duplication of Effort is *Okay*

[alext]

Not at all, I'd be delighted, providing there was a reasonable prospect of getting KDE features into a Motif-based project. After all, one XFree86 seems to be enough.

From the faq:

[iomud]

Writing a new packaging tool from scratch was not an option, because it would have required too much time and it was not clear whether we would have been really more successful than others. Instead we picked the solution which provided for all(!) of our essential wishes a good or at least reasonable solution. The RedHat Package Manager (RPM) version 4 is not a perfect solution, but even with its drawbacks and pitfalls it fulfills the fundemental needs of OpenPKG.

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*

Re:From the faq:

[Nailer]

> The RedHat Package Manager (RPM) version 4 is not a perfect solution, but even with its drawbacks and pitfalls it fulfills the fundemental needs of OpenPKG.

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*

Well, to me it looks like they're acknowledging that no packaging system is perfect. Deb and RPM both do some things better than the other. One is an LSB standard, the other isn't. They made their choice based on that, fair enough.

Re:From the faq:

[iomud]

If it's the standard because it's simply widely in use, sort of like that other operating system thats the poorest of reasons. I really dont want to get into why the lsb chose rpm though. All I know is we have a chance to do things the right way this time, if that means re-inventing the wheel ten times I'd be happy to wait if when it's finished it's the best wheel to date. There's nothing like the disatisfaction of knowing you did something half-assed. I can understand if the skill level of those creating the software is a limiting factor to the quality of the end product but I get the distinct impression that these guys know what they're doing.

RPM?!?!?

[MoceanWorker]

bleh... real men/women compile ;-)

come on.. who doesn't like configuring/compiling... it's the best way to install a program... you customize towards your preference... if anything at least use ports instead of RPM :-\

Re:RPM?!?!?

[lactose99]

Ok...

$ rpm --rebuild package.src.rpm

done

Re:RPM?!?!?

[bojolais]

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.

Re:RPM?!?!?

[meonkeys]

THANK YOU. tarballs/bz2balls are much more cross-platform than rpm or deb packages. If you need an rpm or deb package, make it yourself if someone hasn't made it for you.

Re:RPM?!?!?

[dirty]

I love rpm -tb, but what I really wish was that there was a way to pass arguments to configure. It'd be really great to do:

rpm -tb file.tgz --help
rpm -tb file.tgz --with-neato-completo-feature

I just wish that you didn't have to muck with the spec file for such a simple thing.

time revision?

[mattdm]

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.

Re:time revision?

[leandrod]

You lack information, please investigate more before passing opinion.

You are comparing *release* dates, which are totally irrelevant, and so is the initial release state of dpkg and rpp.

The point is that Red Hat forket dpkg -- rather ignored it altogether -- to create rpm because they suffer from the Not Invented Here syndrome; they didn't want to participate in the political and technical Debian open decision making. And in doing so they created a worse packaging system that has worst policy decisions built in.

As for the initial state of dpkg and rpm, the point is that dpkg has the future built in, while rpm was and will always be badly crafted.

Re:time revision?

[mattdm]

You are comparing *release* dates, which are totally irrelevant, and so is the initial release state of dpkg and rpp.

No I'm not. Why should Red Hat necessarily go with one unfinished unreleased project over another?

As for the initial state of dpkg and rpm, the point is that dpkg has the future built in, while rpm was and will always be badly crafted.

In what way?

Re:time revision?

[leandrod]

Yes you are. Red Hat went with an unfinished project because it was their own. Not invented here syndrome, and wanting control.

In the way that dpkg was made to support sound, forward-looking policies, while rpm just to make things work without giving it much thought. The result is that there is a multiplicity of overlapping tools to help overcome shortcomings of rpm at the same time as it has unnecessary complexity (like versioning), while Debian tools are so well thought-of that even apt was made extensible enough to serve rpm also.

RPM's

[Will_TA]

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:RPM's

[Will_TA]

Easy install yes.
Easy Uninstall?!!!

I have to reinstall my Windows System, once or twice a year simply beacause of the rubbish that Windows leaves on my hard disk from the stuff I've installed and uninstalled. A well used Windows box, with new software added, periodically (like once a month, when the new PC's mags come out) will not last more than a year with out being either slown down, or wibbling badly. (At least, in my experience).

Being Microsofty is also releasing unfinished code, because somebody is going to release their's before yours (and is going to therefore dominate the market). People who manufacture cars would not forget the safety test, because someone is going to release a similarly themed car would they? (Having said this, it is not really the same thing, but it does get a point across. Remember the Comdex thing...)

Why settle on one package format?

[adlam.bor]

The FAQ says that OpenPKG decided to go with RPM over all the others for whatever reasons. What I'm wondering is, why bother limiting yourself in that way? Meaning, isn't it a trivial matter to figure out what package type a file is, and use the appropriate tool to handle it? My point is, I think that rpm, deb, and slackware's format are all mature enough that you can't really argue one over the other without getting into taste. Wouldn't the REALLY smart move be to try to come up with a tool that offers convergence? (not saying that nobody hasn't, but I am saying that I think it's an outdated idea to go with one specific format over any other)

It's too bad

[DaveBarr]

There's two main roads to take when trying to develop a solution for this problem. The first way (the OpenPKG way) is to pick a package system and use it across all your platforms. This ensures that your package system will be incompatible with the majority of your systems. (As a side note, it is too bad that they chose RPM on top of this). However, you at least get to use one tool for all the stuff you add.

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.

Too little, too late

[Anonymous Coward]

Nice try guys, but no. Unix is already too segmented and this packaging system will not change things one bit. This is a non-NLS supporting, non-GPL'd implementation of an uninspiring packaging system which may or may not support other versions of Unix besides Solaris, BSD, and Linux. Their FAQ even contains the question "OpenPKG breaks with a few things from the good old Unix days. Why?" Thanks, but no thanks.

The problem with this...

[printman]

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.

Re:The problem with this...

[warkda rrior]

If you had checked the openpkg website, you would have noticed they use the same concepts as RPM, but they do not require an installation of RPM to be present.

Sounds a lot like "openpackages"

[T-Punkt]

When I read the title I first thought about
openpackages "the new standard for open source binaries"

http://www.openpackages.org

I'll never tourch RPM again if I have too

[smnolde]

The first time I typed "make install clean" in the FreeBSD ports tree I told myself I'd never do roothat again or RPMs again.

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.

Re:I'll never tourch RPM again if I have too

[Omnifarious]

What's the matter with RPMs? I don't understand what the problem people have with them is at all. They've always worked perfectly well for me. The only problem I've encountered is the dependency problem, but things like red carpet solve that really well. So, what's your problem with them?

Re:I'll never tourch RPM again if I have too

[AKAImBatman]

The only problem I've encountered is the dependency problem,

Dependency problem? You don't know the half of it! Last time I tried to install RedHat (out of curiousity), I found that trying to do something as simple as upgrading Xfree86 from 4.0 to 4.01 required me to update just about every piece of software on the fscking system! (What the hell does XFree need bash dependencies for anyway?) Then to add insult to injury, some packages actually needed you to downgrade certain software (which can't be done unless you uninstall the current version which it won't let you do because that will break other software). And some packages even have circular dependencies that prevent you from installing anything unless you work some kind of RPM command line voodoo!!! Don't forget that some packages need differing versions of the RPM program. And what the hell is the RPM packager doing requiring KERNEL RPMs??!!?!?!!?!

AAAAARRRRRRRGGGGGHHHHHHHHH!!!!!!!!!!!!

Want my opinion? RedHat can take RPM and shove it. I'm sticking with BSD.

Re:I'll never tourch RPM again if I have too

[wowbagger]

Of course BSD doesn't have this problem: the tree is maintained by a very small number of groups, all of whom are in close communications with each other, so they keep their dependancies well groomed.

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_b uild_3 of this package, and I won't accept any other version DAMMIT!).

The problem is NOT in the package format, it is in the absense of any centralized agency performing QC on the builds.

Re:I'll never tourch RPM again if I have too

[smnolde]

I don't have the dependency problem with FreeBSD. All the dependencies are handled automagically with the pkg/ports system. If the dependency isn't there it is downloaded and installed automatically.

That's the beauty of the ports system! I have these targets and more with the ports collection:
fetch - Retrieves DISTFILES (and PATCHFILES if defined) into DISTDIR as necessary.
fetch-list - Show list of files that would be retrieved by fetch.
fetch-recursive - Retrieves DISTFILES (and PATCHFILES if defined), for port and dependencies into DISTDIR as necessary.
fetch-recursive-list - Show list of files that would be retrieved by fetch-recursive.
extract - Unpacks DISTFILES into WRKDIR.
patch - Apply any provided patches to the source.
configure - Runs either GNU configure, one or more local configure scripts or nothing, depending on what's available.
build - Actually compile the sources.
install - Install the results of a build.
reinstall - Install the results of a build, ignoring "already installed" flag.
deinstall - Remove the installation.
package - Create a package from an _installed_ port.
describe - Try to generate a one-line description for each port for use in INDEX files and the like.
checkpatch - Do a "patch -C" instead of a "patch". Note that it may give incorrect results if multiple patches deal with the same file.
checksum - Use distinfo to ensure that your distfiles are valid.
checksum-recursive - Run checksum in this port and all dependencies.
makesum - Generate distinfo (only do this for your own ports!).
clean - Remove WRKDIR and other temporary files used for building.
clean-depends - Do a "make clean" for all dependencies.

I'll never go back to RedHat or use RPMs or deb files again.

Re:I'll never tourch RPM again if I have too

[AKAImBatman]

You are correct in part. The problem is the RPM format has been made core to Linux systems with these poor dependencies. It's similar to the DLL hell in Windows. There is nothing really wrong with MickeySofts DLLs. Most DLLs should be installed in the program's directory, but instead end up in windows/system resulting in DLL hell. Unix SOs are a more elegent solution that removes the "hell" out of managing them.

Same with RPMs. They work as a format, but they are wide open for abuse, And the fact that the creator of the format badly abuses them doesn't help anything. BSD packages are just more elegent.

but even when it's a real circular dependency, rpm -i is hardly voodoo.

It's voodoo when the packages have to be listed in some specific order. Why they needed to be in a different order is beyond me. But of course, these types of circular references shouldn't exist in the first place.

[Kernel RPMs] is also (obviously) not a problem with the package system itself

Once again, a matter of elegence. The package system encourages this kind of abuse.

But it isn't, use rpm -U --oldpackage

Fair enough. But why should I even have to deal with this in the first place? Why can't the system understand compatible and incompatible upgrades automatically and either allow the newer version to be used in place of the older version, or install it alongside the current version?

RPM has to be judged by its current use. The maker of a spoon can't be held accountable for misuse of an ordinary spoon. However, if he intentionally manufactures it with dangerous sharp protrutions, you can bet that people will be pretty upset.

Re:I'll never tourch RPM again if I have too

[tricorn]

It's voodoo when the packages have to be listed in some specific order. Why they needed to be in a different order is beyond me. But of course, these types of circular references shouldn't exist in the first place.

RPM is supposed to re-order the packages automatically, assuming you specified them all in one command. You can either install or upgrade, and it will do the right thing. Of course, there are presumably bugs that keep it from working correctly in some cases, and circular dependencies in install scripts could also cause problems. Circular dependencies are much more of a problem with a source package, though - just think bash, make, gcc, fileutils, sh-utils, glibc, diffutils, findutils, sed, textutils - all of those have to be installed to build any of the others.

Why can't the system understand compatible and incompatible upgrades automatically and either allow the newer version to be used in place of the older version, or install it alongside the current version?

It can, of course, if the package maintainers do it correctly. You could make it have no dependencies whatsoever, or make it have ridiculously specific and superfluous dependencies. You can also screw up Makefiles, install shell scripts, or anything else - for example, use bash-specific shell syntax, but specify #!/bin/sh, and then wonder why people get upset.

Having multiple installed versions of a package is, in general, a difficult issue all by itself. There are many ways to do it, and many ways to try to figure out how to access the specific version that YOU want. Just as an example, a configure script (I think for gcc 3.0.something) wanted a version of GNU make higher than some value - it looked for the first instance of gmake or make in each directory in PATH; unfortunately, it found gmake, which RedHat installed for those programs that think they want gmake only; unfortunately, that meant it didn't find the NEW version of make which I had installed in /usr/local/bin (even though /usr/local/bin was first in PATH), because GNU make doesn't normally install itself as gmake. This was mostly a configuration error with RedHat, since there's no reason to install it as gmake when make itself IS GNU make. Solution, of course, was to either link gmake in /usr/local/bin, or delete /usr/bin/gmake. Point is, a configure script has to be a mind reader to figure out things on a completely unknown system. In this case, it needed to keep looking for both make and gmake in each directory in PATH AND keep looking if the file it finds is not a version it wants. Instead, it looked first for gmake in PATH, then make in PATH, and then did a one-time test on the result of that to determine if it was an acceptable version. In a source distribution system, the resultant error would take any unsophisticated user totally by surprise, with no idea what to do about it (even if they already had the requisite version of GNU make installed and on their PATH).

That RPM happens to be used more by people who are likely to screw it up is more an indication that it is EASIER to use, and thus more incompetent people use it. It doesn't mean competent people should have any more difficulty with it than, say, dpkg or ports or whatever.

Re:I'll never tourch RPM again if I have too

[Derek S]

Ports is great for maintaining a single machine, but if you're working in a production environment you're going to do the builds on a single master machine and type "make package" afterwards. BSD packages are somewhat lacking compared to the other Unix package systems, but they're quite easy to build and tweak. I only wish there weren't a split between the packages and the core OS. "make world" isn't a very practical solution for production servers.

The main problem with Red Hat package management is poorly built packages and poorly tracked dependencies. That has plenty to do with the number of people building RPMs and very little to do with the overall quality of RPM itself.

Re:I'll never tourch RPM again if I have too

[kcbrown]

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.

Very good. So what do you do if you want to install binary-only packages that don't have corresponding source (VMWare comes to mind as one such package, though it might not be ported to FreeBSD)?

Ah. I see. You just install it and track it manually.

Well, as a system administrator, that's not good enough for me. The reason I like to use a package management system is that it makes it EASY to manage the huge number of files on my system. If I'm not sure what bit of software a particular file belongs to, I can query the package manager (not every file has a manpage, you know). Can you do that with ports?

Ports is an awesome way to keep your system up to date, but don't confuse it with a good package manager. They serve different needs.

Re:I'll never tourch RPM again if I have too

[kcbrown]

Ports (and portupgrade) are not only about source. Ports (and portupgrade) can handle binary-only packages, and handle very well VMWare (/usr/ports/emulators/vmware), Opera (/usr/ports/www/linux-opera), etc.

Ah, cool. Ports allows you to determine what piece of software a file belongs to and things like that? If so, then it sounds like a nice solution.

Why RPM?

[Anonymous Coward]

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?

Re:Why RPM?

[Arandir]

I'm all rooting for OpenPackages (not OpenPKG) to get stable. It won't cover Solaris, but it will cover Linux, Darwin and OSX.

But that said, I see one advantage to OpenPKG. Since the binaries inside the OpenPKGs will be different, they aren't portable. The advantage must be that the numbnut build managers at these companies only have to learn one tool. I don't see any advantages for the enduser.

FreeBSD pkg_add

[Shooter6947]

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?

Re:FreeBSD pkg_add

[bservo]

Like a previous poster mentioned above, this isn't necessarily any better (or worse) for the package consumer. This is better for the package creator. To quote chabotc:

You only need to write the 'build and package tool' implimentation once (a so called .spec file). This 'source package' you can then compile on each different architecture and platform.
(resulting in a binary usable for only that platform).

This makes cross-platform/architecture distribution a lot easier, and a lot easier to maintain.

Re:FreeBSD pkg_add

[Sentry21]

With thousands of FreeBSD ports already set up, why should I or anyone switch to this new system?

To add to your point, the only reason anyone would use this is because FBSD ports doesn't come with Linux. If you must run Linux though, run Debian, as it's just as easy as FreeBSD.

apt-get install gnupg

If you use Linux, use Debian, if you use BSD, use FBSD. This new package system is useless.

--Dan

Re:FreeBSD pkg_add

[castlan]

I am already sold on the advantages of Debian over most RPM systems in general. I would like a reply with some info on why FreeBSD is better than e.g. the NetBSD packages/port.

Would you sentence have been better stated as "If you need Linux, use Debian, otherwise use *BSD."
Can you please describe what you know about The pros and cons of FreeBSD versus other BSDs like NetBSD, OpenBSD, Darwin or BSDi? Do you know anything about OpenPackages?

-castlan

Re:FreeBSD pkg_add

[Sentry21]

As I understand it, the FBSD packages/ports collection is substantially larger than Net/OpenBSD. I could be thinking only of OpenBSD, however, as NetBSD may be precisely the same or in fact larger than FreeBSD. If this is the case, I apologize.

--Dan

Re:FreeBSD pkg_add

[castlan]

You are more than likely correct that FreeBSD has a larger collection than either NetBSD or OpenBSD. I have heard various references to ports and to packages, and they seemed to be similar but different... I seem to remember NetBSD having ports and FreeBSD having packages, but it could just be the crack rock. I feel somehow dirty poking around for the answer on NetBSD's site using IE, so I was hoping you could regurgitate some fact for me. But thanks anywho.

-castlan

Re:FreeBSD pkg_add

[Sentry21]

FreeBSD has both ports and packages - I know this, having used ports myself from time to time.

As for anything else, I couldn't comment. Sorry.

--Dan

But I thought....

[--daz--]

... Linux isn't Unix?

Can anyone summarize how this differs from RPM?

[Anonymous Coward]

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.

Cross-platform?

[jlusk4]

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.

Re:Cross-platform?

[mr3038]

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?

Perhaps it's that Win98 and Win2000 practically run the same software. It's win32/x86 only. Similar support would be latest versions of Redhat and SuSE only. Ever tried to compile something under pure Tru64 or Solaris? Those are pretty different beasts compared to basic linux box.

Or it might be that we're simply too 1337 to understand real world.

Re:Cross-platform?

[Tachys]

Cross-platform

Linux definition

"Runs on Linux and Windows"

Macintosh definition

"Runs on Macintosh and Windows"

Windows definition

"Runs on Windows 2000 and Windows XP"

Re:Cross-platform?

[ignavus]

"Win98 AND Win2000" - single vendor

"all flavors of Unix" - many competing vendors

There is a difference.

And "cross-platform" != "universal"

Does slickedit run on CP/M? AmigaDOS?

Re:Sounds neat

[ivan256]

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.

I'll stick with source thanks

[PhilJackson]

I would much rather stick with source installs!

Wrong comparison here

[pallotta]

I see a lot of people here making one big mistake: Comparing this to Apt. Apt relies on files that tell it where to look for a program, then gets this program and installs it. (Along with any dependencies).

This program takes an _already downloaded_ RPM (that's right, just _one file_, at least at once), and then installs it. It doesn't search a centralized ftp for the RPM and then install it.

The real complaint (which wouldn't have had anywhere near the same oomph) should have been:

"Why did they choose RPM over dpkg?"

(Which is only natural because very few people download a .deb and then install it with dpkg)!

Has anyone actually read their documentation?

[Florian]

If you had, then you would know that

• it uses a modified, incompatible version of rpm which will will coexist with "normal" rpm in case the OS it includes the latter. (Unfortunately, the OpenPKG executable is called "rpm" as well, but resides in a different path)
• it builds its own repository/package database separate from the core OS packages
• it uses its own particular filesystem layout
• it doesn't provide apt-like functionalitySo OpenPKG does not replace existing package systems, but is meant as a secondary package system for OS-independent userspace tools (thus allowing to share installed packages across different Unix-like OSs). It breaks all Unix/Linux filesystem/compatibility standards, creates headaches by installing itself as a secondary package manager/database, and thus is unlikely to be widely adopted. (Seems rather like a possible solution for sysadmins who want consistent application installations acrosses different flavors Linux/FreeBSD/Solaris).

Re:Has anyone actually read their documentation?

[moro_666]

alright, let's then face it ... it no good ?
the thing is if i mostly depend on dpkg's
and wanna install a .rpm with this openpkg
and it doesn't recognize my .dpkg's , it's
gonna mess with dependicies ???
like let's make a greater mess than it already
is ???
damn your good :p

Congratulations, ichimunki

[MadAhab]

Congratulations, you just described the FreeBSD ports system.

Re:Congratulations, ichimunki

[Furry Ice]

When I read his post I was expecting everyone to tell him this. I can't believe there's only one little post pointing it out. This guy really needs to do the OpenBSD thing and adapt the FreeBSD system rather than write his own. I doubt he will, though. It seems that everyone who thinks they've come up with a novel idea (whether it truly is or not is another story) has to get half-way through an implementation before giving up...

Re:Congratulations, ichimunki

[ichimunki]

I never said it was novel... where do you think I got most of the idea? Will I ever make it through the project to a release? Maybe, maybe not. Even if I did, would more than eight people use it worldwide? Who cares? As long as developers still provide source code with free licenses, I'll be happy. I only mentioned that I was working on it because I don't expect this stuff handed to be handed to me. But since everyone is throwing in their two cents on package systems, those were mine.

And in doing so I got some good feedback from a lot of people who said that a lot of systems for whatever reason don't have compilers, so build-as-you-go wouldn't work for them (although in some of those cases they are very dependent on their OS vendor, regardless of the underlying package system). So what I'll be thinking about now is how can I make sure that I'm not compiling the same package several times on different systems that are binary compatible. That's probably a big waste of CPU cycles.

And maybe it would be easier for me to learn to build .deb files or RPMs from source packages, so that I don't have to deal with any of this and go off reinventing a bunch of wheels. After all, I'm sure I could set my local web server so that it could be added to /etc/apt/sources.list. But even so, the process of building and maintaining .debs locally needs to be managed somehow.

I state again...

[keepper]

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...

All-leveling Installer

[Sherloch Hemloch]

I would like to first point out that I am in no way, experience-wise, able to do this myself other-wise I'd do it...Could some-one make one installer which could install ALL these different types? I know there are some coding BADASSES out here at /. who could. This could be one of the big breaks that could help Linux gain a larger footing in the desktop market (You know, a kinder, gentler, Linux for the masses and in the process, saving the rest of us from premature hair greying). Please! I fear XP!

Sourcerer

[DRO0]

"Sourcerer" sounds like a cool name, but it looks like it's been taken.

Re:Sourcerer

[JahToasted]

Call the lawyers let's sue them!

Sorry, I forgot that we aren't a big corporation

Re:Sourcerer

[innocent_white_lamb]

Actually, sourcerer is the name of a disassembler for the Commodore 64 and, I think, Apple II. I remember using it back when...

Already being done

[ndogg]

There is a group out there that has been working on unifying the packaging system across all the *BSDs out there. Open Packages has already been working on this, and much of the work has been to implement something that sort of a cross between FreeBSD's ports system and Debian's apt.

At first I thought that this was an announcement of that, but now I know that this is a seperate project with different goals.

It's the FORMAT that is PORTABLE.

[SuperBug]

You dolt! It's the format that's portable, not the package itself. This was created so you can create packages of the same type using the same package management SOURCE on any platform. Not to mention, source packages could definitely be portable as long as the software being packaged had all that was needed for other OSes. It's not trying to do something magical, just practical.

Re:Why RPM? Why have a choice you should say.

[SuperBug]

It really surprises me that they decided to use RPM package format.

I suppose it does surprise someone like you. You use that "other" OS instead of Windows. You prefer CHOICE to stagnation.
If you like choice so much, then understand that this is JUST another CHOICE. You've already chosen not to use this it sounds like to me, so there. You're done. Please move on.

Re:the essential question:

[Bimble]

The question should actually be, "Why switch from .pkg?" (The .app extension is an application bundle, while .pkg is an installer archive.)

The answer is that if this standard package format were usable under Mac OS X as well, then it would increase the number of platforms a developer could distribute packages for using the same package system. Making that part easier for developers means Mac OS X users might get more software packages in an easy-to-use installer archive format rather than extracting from .tar.gz files (thus meaning the user doesn't have to be technically competent to install the program).

Stupid, stupid rat things!

[nagora]

Is it just me or is the fact that this thing even supports binary RPM's self-defeating? How is that going to be cross-platform??

Mind you, using the RPM system is pretty self-defeating too.

TWW

Is this open source - or an ad?

[WillSeattle]

Inquiring /. minds want to know.

Re:Duplication of Effort is *Okay* (not always)

[enjo13]

Where you see multiple options, I see what are essentially forks.

Linux is a mess of different systems right now, and that is NOT a good thing. Competition makes things better, I completely agree. However, when you have to compete with your own side along with everyone else.. now that is a problem. Consider that most projects have a team of people who do nothing but build for the different distributions. Right now most projects put out individually packaged versions for:

Redhat 7.x - whatever redhat is at now
Mandrake 7.x - 8.x
Debian
Suse

It is not uncommon for a Linux user to have to choose between 20 or 30 different packages to get the one that is right for their system!

This is a problem of not having a standard. The fact that we have all of these distributions is a problem. The fact that we have two major desktop environments is a problem. All of this is a serious problem because the Linux world is split into lots of tiny factions competeing with each other for the already small number of Linux users out there.

All of this quickly frusturates a Linux newbie.. and all but a hearty few tuck tail and run back to Windows. The reason is simple. Without some standards in place, the entire Linux movement is hopeleslly duplicating a wide variety of projects and aims. I will not argue that this is poor allocation of resources, the open source world doesn't swing that way. I WILL argue, however, that it creates a rather twisted world for the Linux user. Simply because your machine boots a Linux Kernel does not mean that you are priviliged to all of the software that fashions itself as Linux compatible. A windows user can be fairly secure in the knowledge that they can and will be able to run just about anything out there. This is what I want for Linux.

This long winded response does need a disclaimer, however. I do beleive that some measure of competition is good... I see little danger in multiple distributions just as long as Linux in general can standardize on the important things (packaging and desktop for instance). When this has been discussed in the past everyone always said something to the effect of "Eventually the better technology will win out and that will become the standard"

Of course that hasn't (and will never) happened. In the major overlapping projects no clear winner has emerged, no standard has been produced. Instead the waters are as murky as ever and I can not see anything changing that. That leads linux advocates to make this competition is good!!! argument, and tucking away the repurcussions of that competition (a much higher barrier to entry) away..

Re:Confusion and wasted effort is not *okay*

[Sentry21]

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.

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 .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?

--Dan

let's not forget Gentoo

[Enahs]

A lot of folks are mentioning ports trees . . . anyone who's taken a look at the GNU/Linux port of the FreeBSD ports tree will note that it takes an incredible amount of hacking to get that tree to work under Linux.

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.

dpkg dependencies and equivs

[danish]

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.

You don't necessarily have to package anything to get dpkg to know about it. Simply use the "equivs" program: % apt-cache show equivs
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 /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.

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.

Bluff called?

[alext]

But of course the mods can't answer, and nobody appears to want to answer for them. How very unsatisfactory... perhaps /. needs meta-threads as well as meta-moderators?

Big patches? Easy!

[Penguinoflight]

Come on, if you're doing big patches, it's simple with even the simplest package managers.

#!/bin/bash
/sbin/upgradepkg patch1.tgz
/sbin/upgradepkg patch2.tgz
/sbin/upgradepkg patch3.tgz

(slackware as an example). Why doesn't everyone stop fighting about package managment, and go with something more simple?

RPM doesn't have what it takes to be a mainstream distribution format.

Crossplatform, I think not...

[ffatTony]

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.

Re:Crossplatform, I think not...

[T-Punkt]

Do you really think that FreeBSD, Solaris and *-Linux are the same 'platform'?

Re:Crossplatform, I think not...

[ffatTony]

Do you really think that FreeBSD, Solaris and *-Linux are the same 'platform'?

I think dictionary.com clearly states they are.

Well, there is a standard, on Linux anyway.

[Nailer]

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.

Re:Well, there is a standard, on Linux anyway.

[sethdelackner]

I'm honestly curious, you don't seem to like APT, so what is the non-debian apt-get equivalent?

You know what would make RPM so much better

[Pr0xY]

if RPM had it's dependancies based on _files_ not other packages...then it would work so much nicer, especially with other package systems. My main complaint about RPM is that as soon as I install somthing (such as X, or a kernel) from source that a lot of things depend on, I have to "force" all packages that need it, cause i know i have it.

I mean, how hard is it to add a nightly cron task (similar to locate) that would make an inventory of your files/libraries that RPM could use for dependacy checks?

Also this would make RPM cooperate nicely with other package systems..The point is, RPM shouldnt care where the files came from, just that they are there.

No, no, no

[damas]

apt is a general tool for managing dependencies meaning it works with RPMs, DEBs and whatever else you can imagine.