Slashdot Mirror

Show me a tool that converts portage or rpm data and creates a working Debian equivalent and I'll be impressed.

dpkg -S /some/file/somewhere

You are comparing apples and oranges. For an rpm system to utilize the functionality of apt you simply install one of those apt tools made for your rpm based distro. dpkg is the tool more comparable to rpm. As far as arguing for the superiority of one or the other lets just say that I used RedHat and Mandrake before tackling Debian and would never go back to an RPM based distribution. I wouldn't argue that RPMs are bad in some way, only that the packages themselves and the toolchain to manage them can't do anything that can't be done just as easily in the Debian manner. What makes me prefer it is that dpkg has a more granular, modular approach to the problems of package management that reflects Debian's distributed development. The author of alien has a good package management comparison table here.With the addition of apt you get a comprehensive approach to OSS. If it's out there, it's got a unique place in Debian's package namespace. The only technical point I can think of offhand that I would like to change about Debian is the use of foo-x.y.z.orig.tar.gz for the upstream sources. The distro could distribute that aspect of the source archive by changing the foo-x.y.z-r.diff.gz to reference the original source tarball out there on it's own mirror system for many packages.

Because Debian's foundation is arguably farther ahead of Redhat's. While dpkg vs rpm isn't so much of an issue any more, there are still some smaller areas where dpkg appears to outshine rpm (see here for details). apt is better than up2date, and Debian has the majority of stuff codified in policy or the developer's reference, both of which are very practical documents brought about by years of experience in cooperatively dealing with the problems of assembling a coherent distribution in a cooperative setting, which is something the Fedora project is brand new at. They could have leveraged this sort of experience, but chose to redo it themselves.

This ignores the social contract which is a practical set of recommendations for the overarching ideas of a distro. Gentoo basically lifted this for their own when they started their work. Debian also has a very mature and powerful (if a bit arcane at first) bug tracking system, mailing list setup, and mirror system, all of which provide the extensive ifrastructure needed to run a massive project that is completely independant of any one corporate entity. This stuff was built from the ground up for its purpose, and it provides an extremely solid foundation that keeps the project moving along. Fedora might have some newer packages, but the foundation of Debian down to the social and technical infrastructure is even more solid because it's been hardened over many years of experience.

One very nice utility they might be able to use is Alien which allows you to convert from rpm's to debs and many other formats as well

Rus

This is a comparison of the deb, rpm, tgz, slp, and pkg package formats, as used in the Debian, Red Hat, Slackware, and Stampede linux distributions respectively (pkg is the SVr4 package format, used in Solaris). I've had some experience with each of the package formats, both building packages, and later in my work on the Alien package conversion program.

I've tried to keep this comparison unbiased, however for the record, I'm a fan of the deb format, and a Debian developer. If you discover any bias or inaccuracy in this comparison, or any important features of a package format I have left out, please mail me so I can correct it. Several people have already done so. I'm also looking for data to fill in the places marked by `?'.

This comparison deals only with the package formats, not with the various tools (dpkg, rpm, etc.), that are used to deal with and install the packages. It also does not deal with source packages, only binary packages.

Package format comparison table. featuredebrpmtgzslppkgSecurity, authentication, and verification signed packagesyes[1]yesnonono checksumsyesyesnonoyes permissions, owners, etcyesyesyesyesyes Usability by standard linux tools recognizable by fileyesyesnonoyes data unpackable by standard toolsyes [3] no [4] yesyes [5] no [6] metadata accessible by standard toolsyesnoN/Anono [6] creatable by standard toolsyesnoyesnono Metadata dependenciesyesyesnoyesyes recommendationsyesnononono suggestionsyesnononono conflictsyesyesnoyesyes virtual packages and providesyesyesno??no versioned dependencies and conflictsyesyesno??yes boolean package relationshipssyesno [8] nonono file dependenciesnoyesnonono copyright infono [10] yesnoyesyes groupingyesyesnonoyes priorityyesnonoyesno Special files config filesyesyesnoyesyes documentation filesnoyesnonoyes [11] ghost filesnoyesnonono Package programs binary programs allowedyesno??yesno pre-install programyesyesno [12] noyes post-install programyesyesyesyesyes pre-remove programyesyesno [12] noyes post-remove programyesyesyes [12] noyes verify programnoyesnonono triggersnoyesnonono Scalability no hard-coded limitsyesyes [13] yesnono [6] new metadatayesyes [14] N/Anono [6] new sectionyesnononono [6] format version datayesyesnoyesno [6] What is compared. Security, authentication, and verification. This section deals with ensuring that you know who created the package, and

This is a comparison of the deb, rpm, tgz, slp, and pkg package formats, as used in the Debian, Red Hat, Slackware, and Stampede linux distributions respectively (pkg is the SVr4 package format, used in Solaris). I've had some experience with each of the package formats, both building packages, and later in my work on the Alien package conversion program.

I've tried to keep this comparison unbiased, however for the record, I'm a fan of the deb format, and a Debian developer. If you discover any bias or inaccuracy in this comparison, or any important features of a package format I have left out, please mail me so I can correct it. Several people have already done so. I'm also looking for data to fill in the places marked by `?'.

This comparison deals only with the package formats, not with the various tools (dpkg, rpm, etc.), that are used to deal with and install the packages. It also does not deal with source packages, only binary packages.

Package format comparison table. featuredebrpmtgzslppkgSecurity, authentication, and verification signed packagesyes[1]yesnonono checksumsyesyesnonoyes permissions, owners, etcyesyesyesyesyes Usability by standard linux tools recognizable by fileyesyesnonoyes data unpackable by standard toolsyes [3] no [4] yesyes [5] no [6] metadata accessible by standard toolsyesnoN/Anono [6] creatable by standard toolsyesnoyesnono Metadata dependenciesyesyesnoyesyes recommendationsyesnononono suggestionsyesnononono conflictsyesyesnoyesyes virtual packages and providesyesyesno??no versioned dependencies and conflictsyesyesno??yes boolean package relationshipssyesno [8] nonono file dependenciesnoyesnonono copyright infono [10] yesnoyesyes groupingyesyesnonoyes priorityyesnonoyesno Special files config filesyesyesnoyesyes documentation filesnoyesnonoyes [11] ghost filesnoyesnonono Package programs binary programs allowedyesno??yesno pre-install programyesyesno [12] noyes post-install programyesyesyesyesyes pre-remove programyesyesno [12] noyes post-remove programyesyesyes [12] noyes verify programnoyesnonono triggersnoyesnonono Scalability no hard-coded limitsyesyes [13] yesnono [6] new metadatayesyes [14] N/Anono [6] new sectionyesnononono [6] format version datayesyesnoyesno [6] What is compared. Security, authentication, and verification. This section deals with ensuring that you know who created the package, and

It does have package management: installpkg, removepkg, and upgradepkg. It is far, far superior to RPM-based hell. RPM breaks the golden rule of programming (KISS) with a giant sledgehammer; just look at rpm --help, which I won't list here, as it's 154 lines of help options. That's just inexcusable.

The beauty of slackware's package management is that is doesn't check for dependencies. At first that might seem like a bad idea, but for power users (which is Slackware's target) that is best. What if I've upgraded a package manually, by installing from source (or really any way besides installpkg/upgradepkg)? For Redhat, you've got to fight rpm because it really doesn't like to install without all the dependencies listed in its rpm database. On Slackware there is no problem at all.

Additionally, RPM files suck. How do you get the files out of the package, if you just want to see the files and don't want to install? Use alien to convert it to Slackware tgz format.

And how do you see what files each package includes? For rpm, you've got to use rpm to "query" the binary database. Uck. Not very powerful. However for Slackware, all the files are listed in text files in /var/log/packages/, each file representing a package. You can use any of the many powerful file and text processing tools that come with all GNU systems, for example to see what packages put files into /sbin, just do "grep ^sbin /var/log/packages/*" - now that's powerful! And to find what files are in a Slackware .tgz package, just do "tar ztvf package.tgz".

1) Alien
2) again, Alien
3) If you want to be on the bleeding edge, then maybe debian isn't for you.

Package formats: RPM, DEB, there were a slashdot discussion last month about both package formats and i draw the conclusion that the problem it is not package format, but in the way you package your software.
If you want an unbiased comparison between them check out: www.kitenet.net/~joey/pkg-comp/

Dependencies: Now there are solutions to solve dependecies in both package formats. RPMS solutions are pretty new but it is the right way.
- apt-get: for deb packages and for rpm packages, adopted and developed by Conectiva and Mandrake.
- urpmi: adopted and developed by Mandrake
- up2date: adopted and developed by RedHat, you have to register to use it so it is not the right way, not my favourite.

So that is not the real problem but the way Linux distro package the software.

One of the most frustrating things about using some commercial products under GNU/Linux has been the Red Hat centric methods of distribution: binary RPMS designed for Red Hat that may or may not work with other RPM based distros, and will require quite a bit of hoop-hopping on non-RPM distros such as Slackware, Debian, and all of the excellent Source Based Distros.

You can convert between the various package formats, albiet in a somewhat limited sense, with the Alien package converter.

Why, Alien of course ;)

This works well for me to keep about 30 accounts in sync, most of them just get a minimal checkout of my home directory (5 mb or so), while 3 or 4 get the whole home directory and rsynced files (5 gb). The CVS repository is about half a gigabyte in size these days.

Once something that allows proper file rename tracking, like subversion, comes along, I plan to stop using rsync alltogether, and just check all the files in.

As has been noted elsewhere in this thread, one of the key things is coming up with a consistent directory structure and sticking with it.

Or, you see binary-only packages for user-land DVD support.

Once you have a Time-Warner-AOL sized consumer presence, the barrier for DVD licensees like CyberLink to port Linux/X versions.

Of course, these would be for RedHat/AOL versions - so Debian/Slack/etc users would have to compile equivalent kernel facilities and alien-ate the binary package.

I suppose AOL/TW might be able to add some kind of key-signed binary facility, to ensure that only their distro could support some packages. I do not doubt the ingenuity of next-years CS students in defeating any such measure!

My question is, how is apt so much better than, say, Red Carpet on a RedHat box? It works out dependency issues, just like apt does.

For technical differences, see this article. One of the biggest ones is that debs have a higher degree of dependency granularity than rpms. As well as Depends: and Conflicts: they have Recommends: and Suggests:.

Debian also has a carefully thought out packaging policy. And in Debian, everything is a true Debian package. There is no contrib. So a bug against the package is a bug in the system. This mindset makes a big difference to the quality of the distribution.

You might also be interested in this discussion on this theme.

Slackware was originally created because Patrick Volkerding couldn't get 386BSD working on his computer. So he took the time and created the basis of a truely UNIX based linux distrobution. It's a damn shame no one else seems to have followed his lead.

I don't follow you. What's not UNIX-like about Red Hat, Debian or any other server/workstation distribution of Linux? Perhaps you meant "BSD based?"

Slackware tarballs are still cross platform compatable to other unixes, or windows. Or at least far more than RPMs or DEBs.

One can examine and unpack .debs with standard tools. Please see here. Yes, .deb is missing some functionality. But it does more and is more "cross platform" than most people realize.

Slackware is a sourcefriendly distrobution that is rock solid from the bottom up.

I'd argue that Debian is more source-friendly than Slackware because source packages are an integrated part of the distribution. That's a big part of what makes Debian Debian. Source is available for anything and it is trivial to download, build and install any package from source. The "build depends" field in .deb means that there shouldn't ever be a problem getting all the tools necessary to build it. Those complaining that Debian releases too slowly (they do, but it's for a good reason) can always build unstable source packages for their stable distribution. I don't think it's guaranteed to always work due to build-depends (tools from unstable may be needed), but it should work most of the time.

With alien, I've had no trouble installing RPMs. I've never tried a .tgz, but I can't imagine it would be all that much different.

It is not a wonder that it doesn't die, It is only a wonder that people don't take the time to think about seriously using it.

No it isn't a wonder that more people don't use it. I'll agree with you that it's not a wonder it hasn't died. It will be around as long as it's useful to someone and with millions of people using Linux, the odds are pretty high that this will be the case for some time.

Many people don't use it because they've realized that Debian provides everything Slackware does plus a lot more. I consider it the modern version of the great Slackware that saved us from SLS back in its heyday.

Other people don't use it because they just don't care about building from source and use Red Hat or some other binary-focused distribution. Honestly, what's the difference between downloading source, compiling and installing and installing a binary package? It certainly isn't any more secure. It's only more work and takes time people could use to actually get something useful done.

--

convert packages to/from slack, rpm, deb
http://kitenet.net/programs/alien/

I am sure that in both cases, that it is possible with either some switch settings or additional step somewhere.

I was wondering if the possibility of having a unified database for the packages might be reasonable, maybe an XML/RDF based database which then both apt-get and RPM can use mutally.

I was wondering if some of the concerns of those that aren't big fans of RPM are to use gnorpm and/or Redhat's Up2date. They seem to have some nice GUI aspects that make installing packages a little easier as well as providing for the ability to identify and install needed dependencies like apt-get does.

Or maybe some other tools like Auto Update or AutoRPM

Also would use of the package transalation tools like alien help in the two working together?

I think one of the concerns over all the recent hits on many of the distributions, which was one of the weaknesses in the Standard Linux projects has been inconsistant packaging. Perhaps, combining the projects may be beneficial to both parties so that other innovations and work can be done elsewhere.

BreezyGuy

There is an apt-get version, which handles rpms. Can't remember its location though.

You can use Alien to the conversion between the different package formats.

Search for 'alien' on freshmeat, or go to the homepage or simply:
#apt-get install alien
;-)

-Helmet

It's good to hear that the geeks of tomarrow are getting the classical teaching of yesterday. Those who do not understand history are doomed to repeat it! (land war in asia...) Hence, we better not hear about you spending more money on marketing than development for mentalUNIX...

But one comment as far as package tools: you should really take a look at alien, it handles most of the major packages relatively well. to quote: Alien is a program that converts between the rpm, dpkg, stampede slp, and slackware tgz file formats. You might consider using them to achieve your goals... 'Why build a tank from scratch when B.A. Barrachas can just grab sheet metal and put it on a van!'

--
Gonzo Granzeau

A program that converts between the rpm, dpkg, stampede slp, and slackware tgz file formats with ease is the little-hyped Alien . Apt is swish - especially now when it understands a major file format like rpm - but it would be the cats ass if it had the package conversion capabilities of Alien. Apt should also imitate package management routines like Encap and GNU STOW, pm's that essentially isolate packages, installing programs in their own directories and ensuring cleaner and easier removal. With those killer features, Apt would indeed be the Linux standard, regardless of the distribution your using.

Escape from DLL Hell!: The ultimate Package Manager Howto

#apt-get install alien
#alien -d foo.rpm
#dpkg -i foo.deb

Alien is a program by Joey Hess (the same guy who writes the Debian Weekly News) that converts packages between the rpm, dpkg, stampede slp, and slackware tgz file formats. Note that installed 'alienised' packages are classified by dselect and frontends such as gnome-apt and aptitude under a separate 'alien' section.

MashPotato - Mobile Array of Support Helpers for Potato

http://www.kitenet.net/programs/alien/

--
Kiro

Install alien.

How about a super- alien ? You through a package at it and based on your distro it:

• Converts the package in your format
• Installs it
• Cleans up

It's basically where I wrote down everything I learned about the package formats while writing alien.
--

You mean like the %pre, %post, %preun and %postun scripts in RPM?

You're ignoring the bit where Wichert says "special-case upgrades, handle error-recovery in failed and aborted upgrades, etc." Debian postinst scripts can each be called in multiple ways, with informative parameters. So for example, if all files in a package are replaced by files from other packages and the package "disappears", its postrm is run with parameters that let it know what's going on. Or if you install a package that is replacing a package it conflicts with, and the new package's postinst fails, the conflicting package's postinst gets a chance to deal with this situation. There are all kinds of complex situations like this, enumerated here. I'm not aware of RPM scripts having access to such detailed information.

What libc setup do you have to get such good results? (Although I think you've essentially conceded my point by disabling java because "it does tend to crash Netscape").

Debian's "unstable" glibc2.1+smotif linked versions of Navigator and Communicator 4.[67] are all rock solid on my system, even with Java enabled.

You can get the communicator .deb's here, which you'll probably want to convert to .rpm's for your SuSE distro. with Joey Hess's alien program.

Right now, installing Debian takes a couple of hours. Is any work being done on improving the install process? Is any work being done on making package management less interactive (answer all of the config questions either before or after install, rather than during).

Yes, debconf will allow either of these to be done, as well as limiting the questions you see to only the most important ones.

Here's another set of graphs tracking a free software project -- I've been tracking the number of packages in Debian, as well as how many packages are built with different tools, especially my debhelper tool that most debian packages build with these days.

I'm also seeing linear growth, though the angle is steeper.

You should understand that installing packages not created for your distribution can be problemous, regardless of what package format is used. That said, Alien can convert between many packaging formats, including deb's and rpm's.

That's an illusion. The differences between package formats are mostly trivial nowadays - a correct translation between rpm's and deb's is possible and afaik alien does that. The big problems are not because of package formats, but because of different policies between distributions. Those things cannot be automatically translated between distributions, and a common package format will not fix that.

Missing Document The document you tried to access, /programs/alien/CC, could not be found here at Kite. -------------------------------------------------- ------------------------------ This server has been reorganized, and some pages have moved. The link you followed to get here may be out-of-date. Please either inform the owner of the page that sent you here that their page contains an out-of-date link, or let me know about it. -------------------------------------------------- ------------------------------ In the meantime, here's my guess as to the page you really wanted to go to: I'll bet you wanted to go here. (a 116% match) If that isn't it, either visit the list of all pages on this server, or the main page, to try to find the page you wanted.

go here instead... then choose 'alien...

alien you moron.

The user advantages of .deb include:

• suggested and recommended packages--- these are great when you don't know much about what you are installing
• easy of upgrade--- the system can automatically compare itself to the ftp archive(s) and update any out of date software.

• Development model. Red Hat is produced by a fairly small group of developers working for a company. Debian is produced by several hundreds of volunteers.
• Support model. Red Hat offers commercial support. Debian does not offer commercial support (only high-quality free support; commercial support is available from consultants
• "contrib". Debian has no equivalent to Red Hat's "contrib" section (i.e. user-contributed binaries). People who want to contribute to Debian simply become developers.
• Packaging format. Debian has .deb; Red Hat has RPM. Joey Hess, the author of the alien package converter, has a technical comparison between various packaging formats.

There's also a Reasons to Choose Debian document on the Debian website.

• Development model. Red Hat is produced by a fairly small group of developers working for a company. Debian is produced by several hundreds of volunteers.
• Support model. Red Hat offers commercial support. Debian does not offer commercial support (only high-quality free support; commercial support is available from consultants
• "contrib". Debian has no equivalent to Red Hat's "contrib" section (i.e. user-contributed binaries). People who want to contribute to Debian simply become developers.
• Packaging format. Debian has .deb; Red Hat has RPM. Joey Hess, the author of the alien package converter, has a technical comparison between various packaging formats.

There's also a Reasons to Choose Debian document on the Debian website.

I'd like to be the first to point out that dpkg predates rpm. And rpm was created for purely political reasons not technical. And besides, what good do rpms do if you cant share them between dists?

See this package format comparison