> > On Jun 27, 2012, at 4:03 PM, Bryce L Nordgren wrote: > >> >> >> On Wed, Jun 27, 2012 at 12:16 PM, Shea Levy <[email protected]> wrote: >> >> > - On the level of Nix as a package manager, there is a way to roll back >> > everything but GC >> > >> What do you mean, exactly? You can roll back versions of nix, and if you use >> build.nix in the nix source tree you can build each component as its own >> derivation... >> I can't pretend to know what the original poster meant, but I'd want this at >> least to mean rolling back the stateful information maintained by a package >> too. (maybe by snapshotting the drive before upgrading in case things go >> south?) >> > > The whole trick here is defining exactly what "stateful" means. > >> > - There is a simple way to declare something an acceptable substitute of >> > something else. >> > >> Do you mean substitute in the sense nix uses it, i.e. a way to realise a >> path without building it? Or something else? >> I'd like to know if there's an analog to "provides" and "requires" in arch. >> So if a pure java package needs "a" java runtime environment, it shouldn't >> care whether the jre is provided by the Sun implementation or IcedTea or >> OpenJDK. It also shouldn't care about minor version numbers and may not care >> about major version numbers. If it's not pure Java, and there's native code >> it intends to link against a JVM, then it becomes bound to a particular >> implementation at instantiation time. Same thing for Ruby vs. >> Ruby-Enterprise. >> > > Why would you want dependency assertions? Nix expressions are de facto > encapsulations > of a set of build elements that is a far stronger assertion framework than > Provides: and Requires: > (which involve issues of naming/versions/comparison thatr simply do not > matter for nix). > > I suspect that you are addicted to linux package managers from last century > ;-) > > >> 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. > >> A similar but not identical situation arises whenever an interface is >> defined which may have multiple implementations. A package may depend on the >> interface without depending on a particular implementation, however >> "something" sporting the interface must be available. >> > > You aren't defining "interface" carefully enough to attempt a response here. > >> >> >> > - 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. > >> >> >> > - 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. > 73 de Jeff >
_______________________________________________ nix-dev mailing list [email protected] http://lists.science.uu.nl/mailman/listinfo/nix-dev
