> > 1. Debian has been growing in it's base, not shrinking. > > Growing in number of systems installed or as a PERCENTAGE of total linux > systems? The first number does not count as much as the second number.
I'm guessing both. Among more experienced Linux users, I think Debian is definitely gaining market share. And the Linux market overall is totally exploding. :-) I'd like to collect some hard numbers. Maybe in the next few months I'll do a survey and pull together some stats... > > 3. Debian has a package called alien which will allow the installation of > > .rpm packages on a Debian system. > > SOME rpm packages. Some can be quite a bear to get installed. > Particularly anything from caldera that uses the opt directory. /opt ? Yuck. That can stay on Caldera as far as I'm concerned. > > 5. There is no need for Debian to be the most popular distribution to > > guarantee its survival. > > Agreed, but it needs to be easy for someone to produce a WordPerfect > package for. (as an example). If WordPerfect works on Linux, we can make it work on Debian. I'm not too concerned about supporting a few proprietary packages. A few years from now, there will probably be free versions of most of the mainstream commercial productivity apps that will kick butt (ala the GIMP). > > 6. Someone already wrote an extension to .rpm format (.pkg ??) which > > incorporates the package dependency requirements of a system like Debian. > > I have no idea if Red Hat would go for such a change. Very few Debian > > developers are interested in switching to .rpm as it stands. Our dpkg is > > better. > > Very few DEBIAN developers. When I posted my request on this list for a > web page that discusses the differences/merits between the two, I got a > half-dozen private emails aking me to share any info that I got with them. > Also, I got email asking for the SAME information from folks on the > Caldera list when I mentioned dpkg/rpm. I haven't used Red Hat much (I'm going to play with it some more). Personally, I think dpkg is nicer. rpm is much faster - and I like some of the things they do with their source packages. But their tool is just too monolithic and doesn't take advantage of all the cool things that Unix can do. In particular, the rpm philosophy errs on the side of restricting user interaction. It's difficult to do things with rpm that are simple to do with dpkg postinst/prerm scripts. dpkg is more Unixish, whereas rpm is trying to be more like a Windows/Macintosh installation tool. dpkg is slower, but I think that could be fixed. We also have a great opportunity to improve our source packaging formats and also support auto-compiling. Klee Dienes is working to include cryptographically signed package certificates to the file format (a key advantage of rpm right now). Don't forget, dpkg works nicely in conjunction with a wide variety of tools we've developed - it has proven to be quite flexible. Some of the source code inside dpkg is truly scary however. > There ARE commercial developers that MIGHT be interested in this > information. I suspect that some may not even be aware that dpkg exists > or take it seriously. Currently there are what, 4? linux distributions > using .rpm? More like 4 linux distributions giving up and becoming Red Hat... The main problem I have with the rpm packaging system is that it is written/maintained/controlled by the Red Hat guys for their organization -- not ours. Red Hat is a commercial organization. Conway's Law says: "Organizations which design systems are constrained to produce systems which are copies of the communication structures of these organizations." Think about what that means. Neither rpm or dpkg is a complete, stable, or mature product. I feel there is much more room for improvements and feature enhancements. dpkg and rpm are both "first systems" - which means they are both destined to be scrapped. Eventually, we'll totally rewrite dpkg based on what we've learned - and it's going to be good. Cheers, - Jim
pgpWcvYJKMHoJ.pgp
Description: PGP signature
