On Jun 27, 2012, at 4:03 PM, Bryce L Nordgren <bnordg...@gmail.com> wrote:
> > > On Wed, Jun 27, 2012 at 12:16 PM, Shea Levy <s...@shealevy.com> 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?) > > > - 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. It's not implemented, but it's not impractical to have something like that. It could be implemented with nix as it is today, or even better if Eelco is serious about https://github.com/NixOS/nix/issues/14 . We already automatically pass arguments to functions based on attribute names, we could do that based on other attributes as well. > 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. > > Many webapps will need to specify that "a" database library is present, but > may not care which one. > > 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. > > > > > - 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! :) > Depends on how the packaging is done. We tend toward tightly coupling components with their dependencies in nixpkgs, but it's not inherent in nix. > > > > - 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. > > Hope I'm not muddying the waters. > > Bryce > >
_______________________________________________ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
