by Home » Tue, 15 Apr 2008 06:07:25
erily I say unto thee, that Roy Schestowitz spake thusly:
[...]
This looks very interesting in principle, but some of the assertions
about current package management systems are blatantly wrong:
[quote]
For instance, upgrading some application might trigger an upgrade of
/usr/bin/perl, which might cause other applications to break. This
is known as the LL hellor ependency hell
[/quote]
Rubbish. The RPM spec file, and subsequently the local RPM database,
contains "Depends: fo> >= 2.14" type entries that would preclude this
kind of behaviour. If the installation of a new package would "break"
existing packages, then RPM will refuse to install that new package
without the "--nodeps" option. Using "--nodeps" is tantamount to saying
"I no longer wish to use RPM to manage the software on my system", much
like bypassing RPM and installing from tarballs, for example.
Having multiple profiles with parallel dependencies would not fix this
problem, unless one is prepared to reboot into different installs (since
the root dependency might drill all the way down to libc or the kernel),
and I can do that already without NixOS, or I can run multiple virtual
machines.
Similarly the paper's assertions regarding multiple versions or
supposedly conflicting software is also wrong:
[quote]
~]# man alternatives
DESCRIPTION
alternatives creates, removes, maintains and displays information
about the symbolic links comprising the alternatives system. The
alternatives system is a reimplementation of the Debian
alternatives system. It was rewritten primarily to remove the
dependence on perl; it is intended to be a drop in replacement
for Debian update-dependencies script. This man page is a
slightly modified version of the man page from the Debian
project.
It is possible for several programs fulfilling the same or
similar functions to be installed on a single system at the same
time. For example, many systems have several text editors
installed at once. This gives choice to the users of a system,
allowing each to use a different editor, if desired, but makes it
difficult for a program to make a good choice of editor to invoke
if the user has not specified a particular preference.
[/quote]
For example:
[quote]
~]# alternatives --config java
There is 2 program that provides 'java'.
Selection Command
-----------------------------------------------
*+ 1 /usr/lib/jvm/jre-1.7.0-icedtea/bin/java
2 /usr/lib/jvm/jre-1.5.0-gcj/bin/java
Enter to keep the current selection[+], or type selection number:
[/quote]
So you see it is perfectly feasible to have multiple applications,
providing the same function, with the same name, or even multiple
versions of the same application on the same system (the latter would
require a special naming convention for the RPM, and a parallel set of
"Requires" entries).
This next bit is also nonsense:
[quote]
First, it is hard to guarantee that the dependency specification is
complete. If, for instance, the package calls the python program, it
will build and run fine on the build machine if it has the python
package installed, even if that package is not listed as a dependency.
However, on the end user machine python may be missing, and the package
will fail unexpectedly.
[/quote]
Has the author never heard
