To clarify, when I was writing "user" I meant the developer who uses this package, not the end user of complete program.
> On 01/02/14 19:32, Vladimir Matveev wrote: > > When this API is used directly by the package, then the user *should* > > know about it. He's using it, after all. > > There are developers (direct library users), and then distro > maintainers/admins/users who need to manage libraries installed on their > system. The former should know, but the others shouldn't have to think > about it, yet should (must) be able to override the defaults if they > need to, at least for shared libraries. Presumably we want shared > libraries and static libraries to function similarly, except for whether > the user chooses static or dynamic linkage. Well, it seems that working for a long time with a code targeting virtual machines is corrupting :) I completely forgot about different models of compilation. I see your point. But I think that developing and distributing should be considered separately. Package manager for developers should be a part of language infrastructure (like rustpkg is now for Rust and, for example, go tool for Go language or cabal for Haskell). This package manager allows flexible management of Rust libraries and their dependencies, and it should be integrated with the build system (or *be* this build system). It is used by developers to create applications and libraries and by maintainers to prepare these applications and libraries for integration with the distribution system for end users. Package manager for general users (I'll call it system package manager), however, depends on the OS, and it is maintainer's task to determine correct dependencies for each package. Rust package manager should not depend in any way on the system package manager and its packages, because each system has its own package manager, and it is just impossible to support them all. Rust also should not force usage of concrete user-level package manager (like 0install, for example), because this means additional unrelated software on the user installation. Go and Haskell do not have this problem because they are linked statically, and their binary packages do not have any library dependencies at all. Rust is a different story as it supports and encourages dynamic linkage. I think that maintainers should choose "standard" set of Rust libraries which is OK for most applications, and support and update them and their dependent applications. If there are conflicts between versions (for example, some application started to depend on another fork of a library), then maintainers should resolve this in the standard way of their distribution system (e.g. slots for Portage, name suffixes in apt and so on). Essentially there is a large graph of packages in the Rust world, consisting of packages under Rust package manager control (main graph). Developers are only working with this graph. Then for each distribution system maintainers of this system pull packages from the main graph and adapt it to their system in a way this system allows and encourages. I don't think that it is possible to achieve anything better than this. We cannot and should not force end users to use something other than their packaging system. > > If this API belongs to a transitive dependency, then I don't think > > there is an ideal solution. Either the version is pinned (like in Java > > world), or it is chosen by the dependency resolver. > > If we're talking about pinning to an absolute version (no upgrades), > then I think that's a security / bugfix issue, unless we're also talking > about static linkage in that case (which is reasonable because then the > bug is essentially part of the black box that is the software the user > is installing, and in that case, the software maintainer is also > responsible for releasing updates to fix bugs within the statically > linked code. > > > In the former case all transitive dependencies are guaranteed to be > > intercompatible > > Are they? What if the statically pinned version of a scanner library > doesn't support the user's new scanner, there's an update to support his > scanner, but it's ignored because the software allows only an absolute > version number? I don't think your example is related. By guaranteed intercompatibility I meant something like the following. Suppose your package is called `package`. It depends on `foo-x` who in turn depends on `bar-y`. When versions are always pinned by their developers, `foo` author deliberately has chosen `bar-y` version, and he knows that `foo-x` library will work properly with `bar-y`. This is how Java ecosystem works now. New scanner, however, is not an API feature. Your example seems to support the general point about outdated dependencies, and I generally agree with it. > > because these pinned versions were deliberately chosen by libraries > > developers. > > Who are not infallible, and do/should not get to choose everything about > the target system's libraries. There is also a freedom issue, regarding > someone's right to implement a new version of the library, say, to port > it to a new GUI toolkit. Well, developers choose the libraries they work with, and it is absolutely reasonable for them to expect that the user will have compatible version installed. > > In the latter case there is always a possibility of compatibility > > problems, because it is impossible to guarantee complete compatibility > > - libraries are written by people, after all. > > Yes, but we can encourage it, just like we encourage immutability, even > though we can't force everyone to use it. Absolutely agree with this. Isn't semantic versioning intended just for that? > > Then it is the user's responsibility to resolve these problems, no one > > else will be able to do this. > > But the user can't do this, if new libraries break old programs, or old > programs won't allow upgrading. I believe you mean end user here. Then it highly depends on system package manager of this user. If, for example, he or she uses Portage, then the problem can be solved (at least partially) with its slots mechanism. If it is some other system, then it should be solved by its means. See above. _______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
