On 9 February 2012 01:04, Graydon Hoare <[email protected]> wrote: [...] > I just can't help the feeling that this conversation is geared towards > trying to convince me that there's some aspect of baseline correctness that > is so hard to get right that we can't grow it ourselves (or copy from > 0install, or apt, or any other dependency-resolver) as we encounter it, but > should instead give up now and just use it.
Not at all. Writing a package system is pretty easy (which is why there are so many of them). The most interesting and non-obvious bit of 0install is the constraint solver, which we took, with minor changes, from the algorithms in the literature. See: http://stackoverflow.com/questions/2522362/what-are-the-cs-fundamentals-behind-package-dependency-management Getting security and decentralisation right at the start is quite important (if you start off by assuming that all packages should be trusted with root access, and centrally named, that's hard to fix later). But I don't see cargo making those mistakes. I just think it's a bit sad that every time I want to use a different language I have to learn to use a different installation tool, with its own documentation, syntax, solver, security features, and file-system locations, each incompatible with all the others. But maybe there's no point during the development of a new packaging system where the quickest way to add the next feature is to adopt some existing system. > I don't really feel that's a good option, for a bunch of cognitive > complexity and UI / role reasons I've pointed out already. I don't debate > that 0install does more (and more correctly) than cargo currently does. I > hope it's ok if we crib logic from it when and if we need to. But I don't > feel that's a conclusive argument that we ought to adopt it wholesale as a > system dependency. Crib as much as you like :-) -- Dr Thomas Leonard http://0install.net/ GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 GPG: DA98 25AE CAD0 8975 7CDA BD8E 0713 3F96 CA74 D8BA _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
