Here is a tutorial about apt on rpm-based distributions. This tutorial is split into two parts: in the first it demonstrates how to install and use apt based on an example (apt on SUSE 9.2), and in the second part it will give you an overview of the packages to install and the package repositories for each distribution mentioned above.
HOWTO: Apt For RPM
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Who needs to worry about RPMs or Apt if there is autopackage?
I second that. Autopackage should be used. If people have a problem with it, then contribute to make it better.
I second that. Autopackage should be used. If people have a problem with it, then contribute to make it better.
Autopackage is good for the very few programs that support it, but even autpackage.org specifies that it was not built to be a replacement for the core OS packages.
Updating core compontents of the OS are best left to core tools such as dpkg, rpm, etc. since they will take into account changes/tweaks made for the specific OS. For example because so many distros tweak/change apache’s setup, putting apache in the default /usr/local/apache would break init scripts and other niceties that are provided by the distro.
Now that said, apt on an rpm based distro does kind of suck. Using yum is much better since it is architecture aware and can better deal with rpm’s.
Question now, is there any documentation on creating apt repositories anywhere? On yum it’s either yum-arch $rpmpath or createrepo $rpmpath. I’ve not been able to find any docs on how to do this with apt.
Yast automatically resolves dependencies on SuSE, why do people insist on installing apt on it? It doesn’t provide any advantages.
why apt over rpm? the article doesn’t explain.
doesn’t rpm tell you about dependencies? it does. is it nothing more than an application layer that “fetches” the dependencies… like urpmi?
Thanks but no thanks. I prefer .deb or .rpm to Windows-installer-style-autopackage, thanks. I tend to believe in one of the “immutable law of marketings” that in 10-20 years there will only be 2 package format for Linux (it could be .deb and .rpm or maybe something entirely different, doesn’t matter). Autopackage may solve the distro-compatibility problem in the short term, but it is not the proper long-term solution. The proper solution to compatibility problem is large repository like Debian/Gentoo/etc in which the packages are engineered and maintained to be compatible with each other. There’s no silver bullet.
Creating your own APT4RPM repository:
http://www.pycs.net/lateral/stories/32.html
Why use APT on RPM:
http://www.pycs.net/lateral/stories/31.html
Although the reasons there don’t apply to SUSE much.
Be carefull! APT still sucks on multiplatform architectures as Athlon64. You will face dependency nightmare because apt cannot handle i386 and x86_64 libs at same installation simultaneously (which is no problem form RPM at all).
“The proper solution to compatibility problem is large repository like Debian/Gentoo/etc in which the packages are engineered and maintained to be compatible with each other. There’s no silver bullet.”
This is only assuming that there will be one single distribution in the future, and that every single application author contributes to that repository. Do you see that happening? I don’t.
Unless there is a single repository for everybody, the “huge repository” model simply doesn’t scale mathematically. You *can’t* have every single application in your repository! Small application developers will suffer from installation troubles because their application is not in the repository.
And of course, there’s the issue with commercial software. You can’t put them in repositories. It would be great if everything is open source, but that is simply not going to happen. Commercial software is not going away.
I do not agree with autopackage fans at all. autopackage is not ideal (not to say: really bad) because it encourages people to bypass their native package management. This is especially bad for new users because they believe that autopackage is easier to use, but in fact it is not.
Example: Install your distro’s cdrecord as rpm. Then install k3b as autopackage. Afterwards, try to uninstall the cdrecord rpm -> autopackage will not tell you that you cannot do that! rpm will.
Instead of creating yet another confusing “non-solution”, there is a need for *real* solutions. We must not pretend ease of use by creating something that “postpones” the problems like autopackage, but we must *solve* the dependency problem, therefore apt4rpm is a nice approach.
As far as it concerns commercial software: What is wrong about typing “rpm -Uvh AdobeReader_enu-7.0.0-2.i386.rpm” once a year? It is not necessary to have every single application in a repository. This is not an issue. Repositories are necessary, but not for every single application.
Considering Mandriva stopped development of Apt-RPM and moved to Smart should be telling. Apt fails to resolve quite a lot of dependencies in Fedora and I presume other RPM distros. It’s no substitute for Yum in a lot of cases. Apt doesn’t even work in Fedora Core 4.
“Example: Install your distro’s cdrecord as rpm. Then install k3b as autopackage. Afterwards, try to uninstall the cdrecord rpm -> autopackage will not tell you that you cannot do that! rpm will.”
You mean: not yet. Native package manager integration is planned for post-1.0. It was originally planned for 1.0, but many people were interested in using autopackage even with native PM integration, so we changed our schedule and got 1.0 out of the door more quickly.