Slashdot Mirror
An RPM Port Of APT
A reader writes: "This editorial has been just published on freshmeat: 'After full integration of the RPM [?] patches into APT [?] , it will have the potential to become the standard package management frontend for Linux, shortening the gap between distributions and reducing incompatibility across distributions for at least one important system administration tool. (...) The temporarily-forked version of APT is already fully functional and actually works. Conectiva Linux 6.0 -- the first
RPM-based distribution to support APT -- currently ships with it, and has some repositories that are available for
use with APT.' It can be downloaded here."
It's possible to create a deb package for most apps with about 30 seconds of extra effort (dump standard files into top of source tree, edit to change version name and add any vital dependencies, type fakeroot dpkg-buildpackage and wait). You'll end up with a package that can be dumped into a local apt archive and distributed site wide. I prefer this to compiling stuff by hand and installing because it becomes a real pain to keep track of which versions are installed on which systems I look after. Adding local patches is even easier - apt-get source packagename, apply patches, add an extra entry to the changelog and change the version number so that mine won't be overwritten. Rebuild and I now have a package that's identical to the one produced for my distribution except with the changes that I desire.
Sure, this isn't exactly what you want. A system that could do this sort of thing automatically (maybe some sort of wrapper around install(1)) would make life easier still, but with the current situation the time a decent packaging system saves me easily outweighs the extra time taken to play by the packaging system's rules when installing stuff.
Don't get me wrong, I like Debian for a lot of reasons, but apt is the absolute killer app that keeps me on Debian. I now find myself wondering, if RedHat adopts apt, what would happen to Debian. Would it be enough for me to switch back? I guess the question is how many RedHat users switched to Debian solely because of apt.
One possibility is, of course, that RedHat wouldn't adopt apt because it would cut into their financial stream from RedHat Updates.
Anyone have any opinions on this?
And please don't mod this as a troll. I'm not trying to start a distro war. I'm really only looking for intelligent discourse about how this might change the landscape, especially w.r.t Debian.
Key to financial independence: Spend less than you earn. Save and invest the difference. Do it for a long time.
Maybe it will work, maybe not. Maybe this will lead to one linux. If there's one apt, there's one Debian. Thus perhaps this would make Red Hat people point their sources.list to SuSE's repository as well, or Mandrake's.
:-)
Speaking of mandrake, keep in mind not all distros offer an online download of individual packages. So this may also filter out these pseudo-free distributions.
But this is a giant leap forward for RPM-based distributions everywhere; I'm still not using them though
# debian/rules
Sorry, I really wanted to install Debian, but after 3 hours of trying to configure X by hand I returned to Mandrake. I later even tried to install Corel Linux and then apt-get the rest of Debian, but it only created inconsistencies and dependency problems (besides I only have access to very limited bandwith -modem-).
I, too, am a Mandrake user, but as soon as exams finish, I'm planning on switching over to Debian. I'm sick of RPMs, inconsistant packaging, and that damn Mandrake Update that, for the last couple of months, has only been showing me packages that I've already installed!
The thought of having to set up my own XF86Config doesn't concern me in the least, since I've already done it in Mandrake. I didn't like the job that the automated tool did (some ugly flicker), and I wanted to change the default keyboard settings, so I read the man page. It wasn't so scary.
Of course, I realize that not everyone wants to do that. It's been mentioned already in other threads, but have you considered trying Storm Linux? It's a much more faithful child of Debian than Corel, and I have yet to read one bad word about it. And it has more of the pointy-clicky tools you're looking for.
Everyone says this about RPMs, but it doesn't have to be this way. look at the urpmi set of tools that are included with Mandrake. urpmi automatically takes care of RPM dependencies, and can be pointed at a variety of package sources (eg: local directory, NFS mount, FTP site) just like apt-get can be.
Why doesn't anyone ever mention urpmi in these package manager flaming threads?!?! Are any Mandrake users out there using urpmi, or is everyone stuck at 'rpm -Uvh'?
Lets look at some of these problems... lets say I want to have an mpeg player installed, one that's based on SMPEG. SMPEG uses SDL to render to the screen, so that will need to be included. Now in turn SDL has the *option* (when compiling from source) to include OpenGL support. Now we've got a problem - as a distribution maker do we have our SDL package include OpenGL support (and require Mesa) or not? For someone who just wants to be able to play mpegs and is never going to do any 3D work the idea of being forced to have Mesa installed and taking up space is insane.
The problem is that RPM just has a list of package requirements for each package. A list of other packages that are needed - what it needs is a list of things each package PROVIDES as well, so that several versions of the same package can be produced, with different options etc
> What we need is a packaging system that can correctly detect whether or not dependent packages are installed without having to have a database
You've just described FreeBSD's ports collection. Every port I've installed checks for files (using the standard binary and library paths) and not packages. Ports is not perfect: it builds BSD packages, which are so primitive and hard to manage, I don't even bother uninstalling them, i just write new versions over them (so it effectively has no version control). It'd be nice to have it build RPMs instead, even if rpm isn't the best tool out there.
Best of all worlds would be something with the rich command syntax of rpm, the package flexibility of solaris packages (where you can edit the packing list of an installed package) and the script-like flexibility of ports (which is all makefile-based, so you can edit the logic of individual ports, or all ports)
I've finally had it: until slashdot gets article moderation, I am not coming back.
What we need is a packaging system that can correctly detect whether or not dependent packages are installed without having to have a database. Inevitably, the database will get out of sync the moment you have to compile something from source because no .deb or .rpm file is available right then, or because you have a local patch to fix a bug you need which isn't important enough for enough other people for the author(s) to fix right now (or maybe is to complicated for them to figure out how to roll it back in without breaking things for other people that you don't happen to need to worry about). Once the database is out of sync, then new problems come up, and those are easily fixed by forcing an install or installing from source, and then it just gets worse.
Without a database, it would mean the installer would have to have a way to detect whether the dependent thing is installed or not, and in the correct version. I won't say that would be easy, but it is what would be needed. Until then, based on my past experiences with Redhat's RPM, I won't at all be interested in a fancy packaging system.
now we need to go OSS in diesel cars
This is a great next step for rpm based distributions. However, the cleanliness of debian packaging is only part apt.
Most of it comes from thorough policy and packaging guidelines from The Debian Documentation Project. Until other distributions develop such comprehensize packaging policies, the package will not interrelate as well (read - dependency problems will screw up apt). Debian maintainers spent a lot of time thinking out these compehnsive guidelines.
I can rarely upgrade Redhat distributions cleanly without tons of rpm commands ignoring dependencies - however, I find this trivially simple with debian. And the capabilities of dpkg and rpm offer no advantages. But the packaging policies do.
Apt will help a lot though.
This also shows that competition in Free Software is good. If debian innovates, the innovations can be copied to rpm based distros. And everyone wins.
- The multi phase installation. Packages are unpacked and configured in
different steps.
- Maintainer scripts. Debian has a rich and well defined set of scripts a
package can provide in order to leave things configured. They stop and start
services, check the system, update files, etc.
- Strict policy. Debian packages are carefully made so as they work
together. There's a long policy document that specifies what should happen,
how and were, so: no suprises from that new package.
- Virtual packages. A package must be able to depend on certain
"interface" or capability being present in the system, without having to
know which package provides it. E.g.: if a package wants to send a mail, it
will use the tradicional
/usr/sbin/sendmail interface, and depend on a
package wich provides mail-transport-agent.
- Drop file dependencies. They are dirty and evil, as everybody knows.
- All packages involved should be of high quality. There's nothing you can
do with all this measures that will stop a broken packages from giving
trouble to users.
- Several "subpolicies", so emacs, perl, sgml, etc. subsystems could work
together, trigering the registration, compilation, etc. of things when
packages are installed or removed.
- A way for competing packages to be installed, this is made in Debian
with alternatives and diversions.
- Config file handling. The system should never overwrite a config file.
In Debian, dpkg checks if the file has been modified since the package was
installed, and it will ask the user if the package wants to install a new
version. The user could then diff the files, edit, accept or reject the new
version.
A lot of work, perhaps several years... If these are the recognized goals of a distribution, so we should drop everything and make Debian a standard.. =).* Assuming Andover has another $100,000 to toss away on a contest with rules and vote counting that make Palm Beach County look like a beacon of consistency.
Does the scope of the LSB cover anything that apt might play a role in?
If so, what are the opinions out there, with apt inclusion into LSB?
The LSB is very important and will go very far to discounting the naysayers (SUN, Microsoft among them) that linux will deteriorate into disparate competing factions that are mutually incompatable.
I use apt every day and consider it a vital part of my GNU/Linux distribution. If it becomes a part of any LSB standard then everyone else can enjoy the drug-like high of first experiencing apt goodness.
Yes, I do agree that apt is what makes debian superior... But the dselect interface is SO INCREDIBLY BAD that I've never had the patience to finish installing debian, and always wind up dropping back to slackware or even redhat(yuk).
BAD INTERFACE is without question the only reason why debian is not the dominant distro. Someone really should fix this. Make the keystrokes consistant on every page and TEST it with someone who doesn't already KNOW it.
Now we can use apt on other distros. Hurray. I still would like to use debian though, and I know others who feel the same way.
I quickly returned to Storm Linux which is, as far as i can tell, 100% compatible with REAL .debs only uses a purty (and quite handy actually) GUI. So long as they leave the .debs alone I'm happy.