>> Many webapps will need to specify that "a" database library is present, but >> may not care which one. >Heh: if the web app is so "careless" to not specify which database to use, >there's no reason why other system components should care about a busted web >app.
The point is: sometimes it can use whatever is available without rebuild, so why not let user test various options faster? >> > - There is a simple way to derive a version of package with dependency >> > versions changed (for use with subsituters, mainly) >> Can you expand on this here? How would such a feature help? >> Should I have to recompile all my *.jar files just because I upgraded my >> runtime environment? I hope the answer is no! :) >The answer depends on whether your runtime environment upgrade just broke >your jar files. Oh, let me create a new path with substituted dependencies and check quickly! And if it doesn't break, I still save time w.r.t. a full rebuild. >> > - There is a way to replace subsituted package with a "better" >> > substitution or native build >> Continuing with a Java theme: the Java Advanced Imaging interfaces have a >> (default) pure java implementation as well as a native (accelerated) >> implementation. >If two application choices are equivalent, then there is no basis for choice >and either suffices. >Coin flipping is as logical as any other choosing: revisit the meaning of >"equivalent" if you don't >like what the coin sez. Why not package easier-to-build way, check that a few applications build against it and work, spend more effort building native faster library and be able to try out the same apps without a long rebuild? You are not losing anything, after all. Afterwards, you will be able to ask for a honest rebuild instead of substitution and after it turns out that this works OK, you will replace substituted path with a natively built one. _______________________________________________ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev