[Nix-dev] Dependency Semantics

[Bryce L Nordgren]

On Wed, Jul 11, 2012 at 12:53 AM, Mathijs Kwik <mathijs at bluescreen303.nl>wrote:

>
> But the same thing cannot be said about
> Ruby (in all fairness: Ruby's main goal never was to be a VM) and most
> other environments. Also, some of these "language/platform environments"
> have optional components. Let's say some  imaging library gets updated
> and (for example) python is not able to use it anymore (upstream decided
> to move the python-special-imaging-thingy to a separate package/egg).
> Currently, when python gets rebuilt, it won't be able to detect
> image-thingy headers for a supported version, so it silently decides to
> skip building just that small part.
>

There may be a couple of things I didn't articulate well.

1] I don't see these new semantics as "either/or". I fully expect you to be
able to declare a weak dependency on the python environment and a "depends
on exact build of" for the imaging thingy.
2] I would envision the semantics of java packages to other java packages
to be "depends on exact build of". It's the dependency on the environment
which needs to be weaker.

Consider the example you gave though. Some imaging library triggers a
python rebuild. The newly built python lacks some imaging functionality due
to python bindings on the library being moved to a different namespace and
python's build script can't autodetect it. So far, it's the same result
whether you force all python packages to be rebuilt or not: both rebuilds
are broken. "depends on exact build of" does not prevent what it's supposed
to prevent, it just means that after all the unrelated python packages are
recompiled, the duplicates depend specifically on the broken python. In
both cases, you fix it with a rollback and file a bug with upstream. You
can rollback sooner if you're not waiting for all python packages to finish
being built.

Oh, and BTW: The new semantics are replacing the tricks currently used to
fool Nix into believing there is no relationship at all between the two
packages. They at least allow nix-env to check for the completeness and
consistency of a set of installed software, whereas it can't do that now.
The weaker semantics are not weakening anything. They are allowing
currently missed dependencies to be specified.

Bryce
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20120711/2703d9c3/attachment.html