Paludis, the Other Package Mangler
How Paludis and Portage Differ
This is not a complete list. It's not even vaguely near complete. Rather, it's
a collection of lists of things of interest that are intentionally different
between Paludis and its predecessor, Portage.
For the End User
- A whole different configuration system, making it far easier to maintain
multiple systems, some in chroots, with entirely separate configuration
- Performance. Paludis is fast.
- Low dependency bloat. No Python, no big external crypto libraries.
- Security integration (
paludis --pretend --install
- Multiple repository support, replacing Portage's highly limited
- Support for repositories of different types (e.g. CRAN).
- Simple per-(category, package, version, anything else) environment variable
setting (e.g. CFLAGS) without having to add on nasty external hacks.
- Licence filtering.
- Hook scripts, for running code after a certain action occurs.
- Wrappers for econf, emake, wget etc to allow user defined command bindings
(nice, ionice, taskset etc).
- User definable package sets.
- Repositories can deliver news items, warning the user of important changes
before they take place.
- Ability to sync from Subversion, Git, CVS etc.
- Ability to uninstall packages with dependencies, and safely remove
- Ability to see a report of insecure, unused etc packages affecting the
system, either manually or automatically after a sync (
- Ability to see why a package is
really being pulled in, replacing Portage's
misleading and incomplete tree support.
- Much more fine grained control over dropping dependencies.
- Ability to automatically reinstall scm (cvs, svn etc) packages after a
given interval (
paludis --dl-reinstall-scm weekly).
- Ability to resume failed
compiles with far more control than is offered
by Portage's limited
- Ability to display additional information, such as USE flag
descriptions, when installing a package.
- Secure installation and uninstallation of set*id files,
preventing your system from being left vulnerable after having
uninstalled or replaced an insecure application.
For the Ebuild Developer
As well as the end user advantages, ebuild authors will benefit from:
- Full and correct circular dependency detection
- Per package use masking, and from this per package use combination
- Profile-level use forcing, globally and per-package, and from this the
ability to specify a default in cases where one of n USE flags must be
- Default deep dependency resolution.
- Support for -scm, -try versions.
- Multiple inheritance for profiles.
- Ability to install hook scripts.
- Repository definable package sets.
- Ability to deliver news items to the end user.
- Ranged dep specification support.
- Extensive and easily extendable QA checks.
- Much more meaningful error messages, with proper context.
For the Programmer
- Proper library / interface separation.
- Reasonable internals documentation, via Doxygen.
- Consistent interfaces for different repository types.
- Modularity where it matters.
- Test suites, to detect the impact of changes.
- Type safe interfaces, for detecting errors at compile time.
- A choice of programming language for external tools.