Well, having used Debian quite some time myself I think the author is indeed telling the truth, but by doing so also immediately showing his own lack of experience when it comes to both FreeBSD and Debian (no kidding).YZMSQ said:While surfing on the Google to learn more about our pkgng, I encountered this one:
FreeBSD's pkgng: A broken fork of Debian’s apt-get
Is the author telling the truth? Or just yet another anti-BSD thing?
From the article it becomes quite clear that the author doesn't fully grasp the aspect of package management. I quote (about package management on Linux): "Package managers install software packages requested by the users by downloading them from a trusted repository then analyze what dependencies are required and then download those dependencies from the same trusted repositories."
Yet this isn't true. The package manager for RedHat (-based) Linux distributions is rpm, this stands for "Redhat Package Manager". However, the rpm command can't download packages from an online repository, it can only handle local packages (install, delete, query, etc.). One small exception: if you supply a protocol in the package name (http, ftp) then it will use that protocol to download that single package. But the moment this package has a dependency then you're out of luck because the installation will then fail. Redhat has solved this problem though, if you need access to software repositories you'd normally use the yum command.
The same story applies to Debian. dpkg is the used package manager here (for both Debian as well as derivative distributions) but it behaves nearly in the same manner as rpm does. If you need access to online repositories and the automatic resolve of dependencies then you need to use APT which provides the apt-get program.
So if we now take a closer look at the FreeBSD package manager (I'm not using pkgng yet but so far still resort to the 'traditional' ways) then you'll notice that its actually quite similar to both rpm and dpkg. If you need to then you can use the -r commandline parameter for the pkg_add() program which will use its remote fetching features. However, there is much more to it than that.
Remember how I mentioned that when using rpm you could specify a protocol after which the package would be automatically downloaded?
Well, with pkg_add() this works even more advanced than that. If I want to install the mysql-server package without compiling then I could use this command:
# pkg_add -r mysql51-server
and then this would happen:
Code:
root@smtp2:/usr/ports #pkg_add -n -r mysql51-server
Fetching ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-9.1-release/Latest/mysql51-server.tbz... Done.
pkg_add: package 'mysql-server-5.1.66' or its older version already installed
So basically all I needed to do was to supply the -r commandline parameter after which the program automatically knew from where and how it should grab the package I was after.
But there's more. Remember my comment above that both rpm and dpkg could grab a package from a remote location but couldn't satisfy any dependencies themselves? (for that they rely on yum and apt-get respectively).
pkg_add() can, according to its manual page. It'll use the @pkgdep directive to check for package dependencies and (I quote): "If any of these required packages is not currently installed, an attempt is made to find and install it; if the missing package cannot be found or installed, the installation is terminated.".
So basically pkg_add() is taking the whole package management into much more advanced directions than the "Linux package managers" currently support. Where both rpm and dpkg need to resort to external tools the FreeBSD package manager basically provides an "all in one" kind of solution.
Of course in the end its all comparing apples and oranges here. Because if you really need to resort to using pre-compiled packages then maybe FreeBSD simply isn't the right tool for the job at hand. The Ports collection is there for a reason; and one of those is providing full yet easy control over the way your software gets build and set up.
Sure; it takes a little longer to install Apache for the first time. But it also results in an Apache version which is fully tailor made to the way I need to have it setup. For example; getting suexec to have its base directory sitting on /home instead of /var/www/cgi-bin or some other obscure location. The only way to change that on Linux is to... Yups: manually compile the package yourself.
And that's not even mentioning other advantages; like making sure Apache doesn't provide support for things I don't want to have included. For example; on my servers I don't need user directories so support for those haven't been included at all.
Now I know what some people are going to say: "Apache has a modular setup, so you'd only need to make sure it doesn't load the modules.". And that's true. However, if the module simply isn't there in the first place then it also becomes a lot harder to abuse it. Now, I don't think there's much to abuse with mod_userdir but the fact remains that if you don't need it at all its even better not to have it around in the first place.
On FreeBSD I can set this up myself. On Linux you either risk package inconsistency (by removing such a module manually yourself) or.. Here we go again: you simply recompile and re-install the package yourself.
I don't really agree perse that this is a troll blog, though it sure looks like it. But from what I've read so far the author simply shows an incredible lack of experience.
What I personally consider to be extremely funny is that he included Slackware with his examples of Linux distributions which allegedly provides a full fledged package manager. Even though Slackware is often referred to as "A copy of Volkerding's hard drive" by Debian fanboys because they feel it lacks a decent package manager.
Edit: Null-edit & s/setup/set\ up/