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