On 31 January 2012 00:22, Graydon Hoare <[email protected]> wrote: > On 1/26/2012 12:36 AM, Thomas Leonard wrote:
Thanks. I'm documenting these issues here: http://0install.net/why-not.html I've added your replies to our Google Docs spreadsheet here: https://docs.google.com/spreadsheet/ccc?key=0AlQ_ban3-1YrdFJfdlJwNkpENUdMVXJRbE04d29LN1E >> Yes, simplicity is a big problem. Unfortunately, all package systems start >> simple and grow more complex over time :-( > > All systems of any sort start simple and grow more complex, yes. But one > sometimes "starts new" to see what level of complexity is legacy and can be > safely discarded. We live in a world with pervasive distributed version > control now. We didn't used to. Agreed. Although 0install pre-dates Git, it (like Git) was influenced by Monotone (using hashes of trees of hashes to identify revisions). [...] >> That works if you don't have diamond dependencies (most systems seem >> to start this way). But then what if I have: > > No, we very specifically built the versioning scheme in our crates to permit > loading and using multiple versions of a library in the same binary (with a > deterministic, acyclic dependency graph). IOW the "diamond" doesn't have a > join point unless they're metadata-equivalent versions. This is baked into > rust's library name-mangling scheme. If I understand what you're saying: - if a crate A depends on B, and - B depends on C, then - A does not see (or conflict with) symbols from C. If A does depend on C, it may use a different version without conflicts. That's good. I think all modern systems should do that. Ceylon is the same, I think, and ebox (using 0install) uses the same idea to protect applications from the effects of malicious libraries. But it doesn't remove the need to handle diamond dependencies. Very often (most of the time, I think), if two libraries depend on a common one then it's because they need to communicate using a common API or common set of data-types. For example, if I write an application using GTK to handle windows, and I import a widget library, then it's no good having the widget library using its own version of GTK, because I won't be able to embed its widgets in my windows. As another example, >> use logging (url = "git://github.com/user/logging.git", vers = "1.12.3"); >> use foo (url = "git://github.com/user/foo.git", vers = "1.0"); >> >> and foo has: >> >> use logging (url = "git://github.com/user/logging.git", vers = "1.12.4"); > > You wind up with two copies of logging in your process, and they don't > conflict because all their names are version-qualified and there are no > singletons or global (unless you do unsafe things; don't do that). This is > what we built already. Sure, but now the user needs to manage two separate logging configurations for the same application, or risk them overwriting each other's log files (although this is probably a bad example, as I see that Rust very sensibly has built-in logging support). By the way, does this mean that a Rust program must link against exactly the same version of the library that was used at build time? e.g. if I upgrade libssl then I must rebuild all applications using it? -- 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
