On Mon, 2002-01-28 at 17:42, J.A. Magallon wrote: > > On 20020128 Bryan Paxton wrote: > >On Mon, 2002-01-28 at 14:00, Christopher Samuel wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- > >> > >> Hi folks, > >> > >> I'd just like to add my voice to the requests to update the APT package > >> listings for Cooker - I started playing with apt-get before Xmas and managed > >> to upgrade my 8.1 box to Cooker, but nothing since the 24th. > >> > > > > I vote second for that, I'm very interested in trying out apt-get for > >RPM. From what I've heard, it seems to work without a hitch (as much as > >any software can). > > > > I don't. Instead of trying to integrate an alien in mdk, why could not > time be spent in building a curses version of rpmdrake, for example ? > Make mdk tools better than apt, not just clone apt for cooker. >
It's about choice... Diversity can be a good thing, it often times pushes on project ahead of the other, and vice versa. But let's have a real life example: Mandrakesoft produces SNF (Single Network Firewall), I can only assume that their intentions are to take this further. This being a firewall oriented target, suppose the admin simply wants to strip the GUI stuff away, and have it a bare bones system (as any firewall should really be). If he or she was to choose rpmdrake, well that ruins the plans for stripping the system. Now, I know what you're going to say, "Well what about urpmi, the backend? It's a CLI, why not use it?" And my response to that would be that urpmi has a barage (only in opposite of apt) of dependencies... [evil7@sQa evil7]$ rpm -qpR urpmi-3.2-2mdk.i586.rpm eject webfetch perl-DateManip >= 5.40 perl-gettext rpmlib(VersionedDependencies) <= 3.0.3-1 rpmtools >= 4.0-5mdk /bin/sh /bin/sh rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(CompressedFileNames) <= 3.0.4-1 bash perl-base [evil7@sQa evil7]$ rpm -qpR apt-0.3.19cnc51-1mdk.i586.rpm rpm >= 3.0.5 /bin/sh /bin/sh rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(CompressedFileNames) <= 3.0.4-1 ld-linux.so.2 libapt-pkg.so.3.1 libbz2.so.1 libc.so.6 libm.so.6 libpopt.so.0 librpm-4.0.3.so librpmdb-4.0.3.so librpmio-4.0.3.so libstdc++-libc6.2-2.so.3 libz.so.1 libc.so.6(GLIBC_2.0) libc.so.6(GLIBC_2.1) libc.so.6(GLIBC_2.1.3) You can plainly see the difference, (libapt-pkg.so.3.1 is provided by apt). Minimalization of software is one of the key elements to security. So, in that respect, which one would be the better choice? Furthermore, I've never set up a firewall or any other security related system that had perl installed on it, it's just bad news (more options for an attacker). But take a desktop user, they dont' wanna fool around with the CLI at all, in general, and in general at first. In that case, urpmi and rpmdrake would probably make more sense for them. Sadly, both sets of software fail to do the impossible, making package management on Linux easy (yet robust). This is where the development of RPM comes in, and new packaging systems (hasn't been one yet that is better though IMHO). One final note, is mandrakesoft ever going to provide it's own repos of updates? Bandwidth is expensive yes, but look at the redhat route. I would certainly pay 5 dollars a month for a service like that (I already pay for redcarpet). The security and reliability of co-mirrors is ridiculous. Time to take the next step, don't ya think? That's my 50 dollars errrrrr 2 cents : ) -- Bryan Paxton Public PGP key: http://www.deadhorse.net/bpaxton.gpg
