On Wed, Jul 11, 2012 at 12:53 AM, Mathijs Kwik <[email protected]>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
_______________________________________________ nix-dev mailing list [email protected] http://lists.science.uu.nl/mailman/listinfo/nix-dev
