Differences between version 26 and previous revision of PackageManagementTool.
Other diffs: Previous Major Revision, Previous Author, or view the Annotated Edit History
| Newer page: | version 26 | Last edited on Sunday, July 10, 2005 7:11:00 pm | by PeterHewett | Revert |
| Older page: | version 25 | Last edited on Monday, June 27, 2005 3:44:18 pm | by AristotlePagaltzis | Revert |
@@ -1,10 +1,10 @@
-Most PackageManagementTool~s revolve around binary distributions of [Package]s
. That is, they consult a repository of pre-compiled packages and install the package best suited to your system architecture. They may also offer source packages, allowing you to build the [Package] locally with whatever patches and optimization or configuration options you may have chosen. Other PackageManagementTool~s are source based - they may not even provide binary [Package]s at all, but at least try really hard to avoid them. These download the sources for a [Package], apply any vendor-provided patches, then compile on the local machine. This process takes considerably longer, but some people swear it gives them much better performance. It does have the advantage that you can tailor the system very closely to your desires, but is not much fun on slow machines, particularly for the desktop where such mammoths as [GNOME], [KDE], [Mozilla], and [OpenOffice] are waiting to occupy your machine for hours on end.
+Most PackageManagementTool~s revolve around binary distributions of [Packages |
Package]. That is, they consult a repository of pre-compiled packages and install the package best suited to your system architecture. They may also offer source packages, allowing you to build the [Package] locally with whatever patches and optimization or configuration options you may have chosen. Other PackageManagementTool~s are source based - they may not even provide binary [Package]s at all, but at least try really hard to avoid them. These download the sources for a [Package], apply any vendor-provided patches, then compile on the local machine. This process takes considerably longer, but some people swear it gives them much better performance. It does have the advantage that you can tailor the system very closely to your desires, but is not much fun on slow machines, particularly for the desktop where such mammoths as [GNOME], [KDE], [Mozilla], and [OpenOffice] are waiting to occupy your machine for hours on end.
There are several main 'flavours' of PackageManagementTool in use in various LinuxDistribution. These include:
<tt>rpm</tt>:
- RedHat [Package] Manager. Obviously, RedHat uses this, but [Mandrake]
and a handful of others do as well
. File format is [RPM].
+ RedHat [Package] Manager. Obviously, RedHat uses this, and so to many other distros
. File format is [RPM].
<tt>dpkg</tt>:
This is [Debian]'s [Package] manager. KnoppixLinux, [Progeny] and other LinuxDistribution~s are "Debian-based" and thus use this as well. FileFormat is [Deb].
<tt>.tgz</tt>:
[Slackware] uses nearly plain TarBall~s that include a description and a postinstall script.
@@ -22,4 +22,6 @@
[Yum]:
FedoraCore's conconction. The vendor-recommended way to install software on that distribution.
[APT]:
One of the best tools around. It traditionally wraps <tt>dpkg</tt>, but there is an AptForRpm variant now (and rapidly gaining popularity). It was the first front-end to nicely handle dependencies: <tt>apt-get install foo</tt> will automatically download and install not only <tt>foo</tt>, but also any unfulfilled dependencies <tt>foo</tt> may have. There are lots of supplemental utilities surrounding -- see DebianPackageTools.
+[urpmi]:
+ [Mandriva's|Mandriva] package management tool based on [RPM].
