Slashdot Mirror
APT - With Your Favorite Distribution
Then there is another solution from Connectiva in Brazil, which has made something called APT4RPM -- basically an APT wrapper around RPM database on your machines, so you can use all of Debian's APT features (sans DSELECT feature) to upgrade your packages, or your entire distribution. (So now you can use your favorite distribution AND APT to update it.)
Two open source developers have improved Connectiva's solution to work with ANY RPM-4 based solution, and the [not finished yet but seems pretty stable solution] is at APT4RPM project pages in sourceforge. I have decided to give a test on my Redhat 7.2 machine. I installed the binaries, edited the /etc/apt/sources.list (just remove the # from your distribution's mirror), typed "apt-get dist-update," crossed my fingers -- and lo and behold, 48 new packages were installed, 7 were upgraded, and I only had to press "enter" to start the ball rolling!
So, for those of you who want to test it -- the URL is above (and if you could help with creating mirrors for your favorite distribution - that would be very helpful, thank you), you might want to try it. Just don't forget to read the FAQ before doing anything, and report bugs to the authors. Note: although the binaries are for Red Hat, the SRPMS are right there so you can just recompile it on your favorite distribution. Enjoy.
Here comes an example from the real world: Apt/dpkg is no better than rpm. I can install cups without ghostscript and apt doesn't complain. I have this dependency with my printer, most probably others who use CUPS with a laser printer don't have the dependency.
.SPEC file said so.
I don't see any problem here, either. All the dependency "problems" I can imagine can easily be solved by a flatrate, some time and a big harddisk.
On SuSE, I often used --nodeps for rpm, cos I *knew* that mutt doesn't *require* a spell checker, even if the stupid
reduce(lambda x,y:x+y,map(lambda x:chr(ord(x)^42),tuple('zS^BED\nX_FOY\x0b')))
First of all, this is oooold news. Connectiva has been around for a while, and they've used apt-get with RPM all that time. 'apt-get' was coded to be relatively package-manager-independant, so it's no surprise that another distribution has adopted its use.
Anyways, to my main point. You're *still* going to have dependency problems. This isn't a magic wand. It works well in Debian because a) there are hundreds of mirrors, they all carry the exact same packages, and they're all administered with a decent degree of competence. And b), the Debian packagers *care*. The packages install so easily because, generally speaking, Debian Developers arn't lazy. In fact, following the Debian Policy(a big reason why packages under Debian install and work so well) is actually kind of a pain in the ass. But it's still followed.
Yeah, apt-get is great. But it's just a tool to deal with packages. If the packages it's dealing with are crap, then it won't help you one lick. Most Debian Developers take care of a *single* package. There is a decent minority that takes care of a number of packages each, and there are a very very few that take care of dozens of packages each. And these people *use* their packages; they use the apps they package, they use Debian, they use their Debian packages.
Can you say all that about Red Hat? How many thousands of packages do they have, and how many package maintainers? A few dozen? Full-time? That's being optimistic. You're still looking at a stunning lack of man-power(when compared with the alternatives).
Barclay family motto:
Aut agere aut mori.
(Either action or death.)
What you've said is the true power behind Debian. It's not really apt, as everyone likes to claim. It's in the social structure behind it. The policy and the extensive testing of each package makes the system work together so well to get rid of dependency problems. The fact that you've got maintainers looking after their individual packages and an open process with strict guidelines forces everything to behave.
Sure, dependency problems happen, but far less often than I ever had to deal with in Mandrake or Redhat, and when they do happen they are fixed very quickly. How many times have I seen in the unstable changelogs on entirely new package uploads with the only change being some minor dependency problem which hadn't affected me?
The fact is, Debian's social structure is what gives it its power, not the tool it uses. While apt is a powerful piece of work, it's the community that gives Debian that special glow that all these other distros are trying to emulate.
"I may not have morals, but I have standards."
Rpm is getting a bad rap because it is actually a bit more flexible in practice: because it uses file dependencies extensively, you can, in fact, install rpm packages on systems even if you don't have a whole dependency infrastructure built around them or if some of the files come from manual installations. That's why so many more RPM packages are distributed on people's web sites than Debian packages. But this comes at a cost: as people try to do more (uncoordinated packaging), more things can go wrong. Some of the combinations you might want to install are simply impossible. With apt, you wouldn't even try because it's not a choice. With rpm, you can try but it fails, and rpm is then blamed for the failure.
If you could build an infrastructure like the Debian project around rpm, I expect it would do just as well as the apt/deb mechanism (the automatic download managers already exist).
I use mostly apt/deb right now, but I have also used rpm a lot in the past. Altogether, I think neither rpm nor deb/apt have really solved the packaging and system update problem completely yet. They are both rather imperfect solutions, each with their own advantages and disadvantages.
The wonderfulness that is apt-get, and the dpkg engine that it runs, is two fold:
o apt-get install galeon. Yes to install deps, blam! done.
o The true reason people love it so, and the reason it Works, is mainly due to the hard work, sweat and tears that the package maintainers put into each package. Each maintainer generally only handles either a single package, or just a few. With the 7-8k stable in all but name packages in Woody/testing, this represents a truely huge effort.
Not to belittle other distributions, but Apt has a huge advantage, solely due to the sheer amount of people hours that are put into tweaking every little package until it is just right. For a comercial distribution tho, this is cost prohibitive, and one maintainer must be responsible for many many base packages. The debian maintainers also QA addtional packages, so users arn't so much at the mercy of the setup that the origianal external software authors used.
I hope I don't come across as too much of a zealot, but it is really really really nice.
~.~
~.~
I'm a peripheral visionary.
I wanted to know if you install something using
./configure
make
make install
Is there anyway to uninstall it?
I'm a Debian user, and I think that you're generalizing way too much. People love Debian because it's the best at the things that they care about, and they have the capability to contribute to it.
As a Red Hat user, you don't get to contribute unless you work for Red Hat. Since you got flamed hard on the Debian list, you must have posted there. If you posted there, then you must have wanted to contribute.
Now, is using Red Hat scratching that particular itch? No? Then why haven't you started your own distribution to scratch that itch?
On the other hand, perhaps you don't want to contribute to a distribution. Why then in that case would you care about the Debian list? I use Debian and don't post to the list because I'm not a Debian developer.
To sum things up bluntly: don't cut yourself off from a distribution that is top notch just because you think that the developers (many of whom are not the same people who treated you badly) are jerks. You can use the distribution without ever talking to them.
If tits were wings it'd be flying around.
The Debian community is so passionate because it is a distribution supported 100% by the people, and only the people. There's no commercial entity that funds the Debian Project. The release manager doesn't get a bonus if he gets the release out ahead of schedule, and the QA team doesn't get paid to manage packages that fall through the cracks.
Every single aspect of Debian's development, support, and growth comes from people who care about it enough to contribute their time. Does this tend to breed fanatics? Quite possibly. Is it understandable? Certainly to me. I don't see such fanatical support of other distros, because virtually all of them are developed by a company, not by a community.
Now, if that's not your cup of tea, great. There are plenty of other distros. That's the whole point, after all. That's the beauty of Linux's "fragmentation" that has forever been a point of criticism from the commercial software world which is so used to not having a choice.
Like I said, Debian doesn't avoid these problems because of technological superiority, they avoid it because they don't have different groups of competing packagers. That's great now, but it'll be ugly if they ever fork.
This happened a few times. Connectiva, Stormix, Corel, all essentially Debian forks. Y'know what happened? Corel sucked (And nobody was surprised), but Stormix and Connectiva remained compatible. In fact, it was common for Connectiva users to upgrade straight from an existing Debian install to a Connectiva release, or vis versa.
Just because more than one group is doing the packaging doesn't mean they'll be incapable of following the same rules. That's why Debian works with 300+ people making packages, after all, they follow the rules.
Whether something is a real server or not is not at all about the hardware it runs on, it's about what you use it for. And up to 2.4.16 you really don't want to run a 2.4 kernel on a server. Maybe you haven't had any problems with 2.4, but most people have. It would be much wiser to stick with one of the latest 2.2-kernels for a while until 2.4 has proven itself.
0x or or snor perron?!
The utility of the 2.4 series kernel in production is completely dependent on what your server's functions are. For example, my employer has a specialised audio/video streaming daemon which suffered from (read: design problems) network subsystem performance problems in 2.2. These problems could be fixed with some kernel source modification and recompilation, but that degree of modification should not have been necessary (based on WHAT needed to be changed in the kernel). In 2.4, 90% of the things needing modification can now be set via /proc or sysctl. The other 10% were design limitations in the 2.2 series kernels which have been addressed and resolved (at least, to our application's satisfaction).
On the other hand, I'm still running 2.2 for our SQL server. After 2.4.16 and later have been tested by some other bleeding-edge people with database servers, I'll move it up. The VM problems and changes in the kernel seriously scared me away from making an early upgrade to 2.4.
It's all relevant to application.
.... um, i lost you after "0110100001101001".
Ximian hosts all the packages that are included in your distribution. Including KDE. I've installed KDE with Red Carpet. No, really.
Now, why do package management systems succeed or fail?
All package management systems have two issues: First, figuring out which packages are needed.
Second, going out and downloading them.
The first one is a matter of a file format with metadata and then parsing. It can be tricky but it's basically parsing. The second is a server management and control-of-system issue.
Debian's system, like Ximian's works reasonably well because it's more or less closed: very few packages will ever require something that isn't in one of the mirrors.
Download a random rpm, deb, or tgz from the net, and who knows what you'll get. Maybe it will ask you for something that's in a mirror. Maybe it won't. If you're lucky, it'll ask for something you can find somewhere.
Aaron Weber
Technical Writer
Ximian, Inc.