Verily I say unto thee, that Roy Schestowitz spake thusly:
> NixOS: A Purely Functional Linux Distribution
[...]
> http://people.cs.uu.nl/andres/NixOS.pdf
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 “DLL hell” or “dependency hell”.
[/quote]
Rubbish. The RPM spec file, and subsequently the local RPM database,
contains "Depends: foo >= 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’s 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 of "Buildrequires"? The circumstances he is
describing is broken SRPMs that should be fixed, not normal conditions.
Also his criticism of nominal build environments is rather obtuse. If
there is a "Buildrequires: foo-devel >= 2.4", then there will naturally
also be a corresponding "Requires: foo >= 2.4" in the resultant build,
if "foo" is actually required at all (usually but not always). Again,
I'd consider anything else a bug which should be fixed. This is not a
normal condition.
There's a lot to absorb in this highly technical paper, but from what
I've read so far it just seems to be an attempt to track configuration
changes using profiles, which in and of itself is not necessarily a bad
idea, but the implementation looks rather convoluted, and it would seem
to badly break some important aspects of Linux, such as the FHS and
prelinking. IMHO it's cracking a nut with a sledgehammer.
Personally I'd rather just backup /etc with dump, do a dist upgrade,
then restore individual configs as and when I need them. This approach
is simple and it works. The linear filesystem layout suggested by this
paper seems rather too much like MacOSX for my tastes. Indeed the entire
concept is reminiscent of the Mac-ification of UNIX. No thanks.
--
K.
http://slated.org
.----
| 'When it comes to knowledge, "ownership" just doesn't make sense'
| ~ Cory Doctorow, The Guardian. http://tinyurl.com/22bgx8
`----
Fedora release 8 (Werewolf) on sky, running kernel 2.6.23.8-63.fc8
22:07:05 up 114 days, 18:42, 5 users, load average: 0.00, 0.00, 0.00
|
|