[Nix-dev] Re: Package maintainer coordination problem and Nix

[Mads Lindstrøm]

Hi Peter,

On Sun, 2009-07-19 at 11:48 +0200, Peter Simons wrote:
> Hi Mads,
> 
>  > I was surprised to find, that Nix do not alleviate the dependency
>  > hell as thoroughly as I thought.
> 
> yes, statements like those should be taken with a grain of salt. It's
> mostly propaganda. Basically, Nix does not affect the package dependency

To be fair, I do not think the Nix homepage claims to solve the
dependency hell this thoroughly. I think it was more my imagination and
some comments, from a non-nix'er, that I read somewhere. I forgot
where.  

> structure in any way whatsoever. A package that's being installed via Nix
> has the exact same dependencies it would have if you'd install it on
> Gentoo, Debian, or any other distribution. What can be said for Nix is
> that it is particularly good at detecting unspecified dependencies.
> Arguably, the package dependency structure expressed in nixpkgs is more
> complete and accurate than that of other distributions, but it's by no
> means simpler, easier to maintain, or easier to understand.
> 
> 
>  > If each package, in the Nix subversion repository, explicitly stated
>  > which versions of packages it depended upon, then upgrading library X
>  > would be safe.
> 
> That can easily be done. Packages *can* depend on specific versions of
> other packages. While possible, however, this kind of setup is
> undesirable. Consider a package that depends on Python 2.4. Now there is
> another package that depends on Python 2.5. If you install those two
> packages, you'll end up having two different versions of Python's
> installed. If you consider this phenomenon for a complete Linux system
> with OpenOffice and Firefox and whatnot else, then you'll have an
> installation that is incredible redundant.

Well yeah, if every package depends on it's own version of each library.
Though it was not really what I had in mind. Let me explain what I had
imagined. Let's assume that somebody upgrades library X. Then every
package Y, which depends upon X gets rebuild and if package Y has any
automated tests they get run. If both the re-compile and the tests are
succesful the database is updated to reflect that package Y, now uses
library X in the newer version. If they fail package Y keeps using the
older version of library X.

Note that this process could be done automatically, so no extra work,
except for kick-ass build farm. And of cause, somebody needs to program
this automation.

Also note, that you only get two versions of library X, if some package,
which you have installed, fails to build with the never version of
library X. You could even let the user choose between getting the newest
versions wherever possible, and saving disc space (only upgrading any
dependency upon library X, when all dependent packages Y could get
compiled).

Finally note, that automated tests could be as simple as seeing that
some application can start without segfault'ing. This will not catch
every bug, but a hole lot of them.

> 
> In truth those two packages don't really depend specifically on Python
> 2.4 or 2.5. It's more likely that they'll work fine with any version of
> Python newer than, say 2.0. Then again, Python 3.0 might break them, so
> what you really want to specify is a version range:
> 
>   "python>=2.0 && python<=3.0"
> 
> Nix can do all that. The reason why dependencies aren't specified that
> way isn't technical in nature. The problem is just that figuring out
> those facts is a hell of a lot of work. :-)

What I am proposing is a fully automated solution.

> 
> Take care,
> Peter
> 

I realize that I am rank-newbie when it comes to Nix. So some may see it
as arrogant, that I come here and want to make drastic changes before
understanding Nix thoroughly. But I am really just trying to understand
why you setup is, as it is.


Regards,

Mads Linstrøm


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.science.uu.nl/pipermail/nix-dev/attachments/20090719/aa82f792/attachment.bin