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.
For apt to work to it's full potential you need a have a list of all available packages at the time in the current archive. Which debian has, so the question is how many of the other distros are doing this to make sure all the dependencies are currently in check? Cos I can see a lot of conficts to be had if there isn't one or isn't done properly.
*shrug*
Debian/unstable is where new packages go. Here, packages are often built right from CVS. Yes, if you track Debian/unstable, you might get burnt every now and then from bugs. But on the whole, it's very good; everything is up to date, and it's about as stable and bug-free as a Red Hat
Debian/stable is almost totally static. The only reasons a package in Debian/stable is updated is for security reasons. Even then, usually, the fix will be backported to the version of the app that's in Debian/stable. For instance, if a long-present security bug is fixed in BIND 9.2.0, but Debian/stable asdlfkjasdglakjsdf, then the fix will be backported to that version; the package won't be upgraded right to 9.2.0. Why do this? "Stable" doesn't just mean apps that don't crash. It also means a common platform. Debian/stable will change only very, very rarely. This makes it an ideal target for sysadmins who wish to use trusted software, and for developers who want to target the lowest common denominator.
Yes, all three Debian trees use apt-get; in fact, moving from Debian/stable to Debian/testing is a matter of two or three commands, usually(ditto for Debian/stable -> Debian/unstable, or Debian/testing -> Debian/unstable). Almost all Debian mirrors have all packages from all trees in all supported architectures.
Barclay family motto:
Aut agere aut mori.
(Either action or death.)
Add to your list of communities with offensive users LISP and some parts of Java. I can't stand to read Java books that denounce other programmers and other technolgies, and too many of the LISP books I have read do the same.
Why can't they let the merits speak for themselves? Bashing others just turns users away - users like me who don't care for the politics.
Use a script or scripts -- keep an up to date
list of the ftp-accessible RPM
resources for your distribution. Use --test
with rpm -Uvh and when you have a
dependancy -- just grep your list(s) and
wget anything you need. In all, it keeps you on top of
what is going on with your system.
Not hell at all, IMHO.
I will share the scripts I use for mandrake if anyone wants them.
#netselect-apt unstable; apt-get update ; apt-get -yd dist-upgrade ; apt-get dist-upgrade
Actually, probably replace those semicolons with && so commands proceed only if everything is ok.
It's a good time to be a Debian user :-)
So we have: 5467 source packges (8558 binaries), and 934 registred maintainers. I.e. 6 sources, or 9 binary packs/maintainer, rather than 1-2. Still not bad, though.
First 21 maintainer takes care of 30 sources packages or more, for a total of maybe 1000 (sources) packs. 144 maintainers care about >=10 source packs etc.
Now let's go and look at the bottom of the list:
270 maintainers with 1 pack
141 maintainer with 2 packs
...
While this is a great thing to have, the fact remains that it's the "top 50", or maybe "top 100" who make the most of the stuff, and each of these has a fair number of packs to do. Not that much different from commercial distros.
make
make install
Uninstallation just involves removing the directory. This way I don't need to keep the source lying around and it's easy to change which version of the software I want to use. I usually do a
ln -s /usr/local/emacs-21.1 /usr/local/emacs
so I don't need to update my PATH every time I compile a new version.
The only downsides are that /usr/local gets pretty cluttered and PATH sure gets long, but it's worth it to me.