On 01/02/14 00:12, Tony Arcieri wrote:
On Fri, Jan 31, 2014 at 4:07 PM, Vladimir Lushnikov
<[email protected] <mailto:[email protected]>> wrote:
Just to be clear, I think what you are saying is that you want
version pinning to be dynamic? I.e. when a new version of a
library dependency becomes available, upgrade the package with
that dependency?
I would like a constraints-based system that is able to calculate the
latest API-compatible version of a given package based on rules less
strict than version = X.Y.Z
Agreed, but that's VERY low bar for requirements; I think we need to be
more specific. Apt, debian's package manager, for example, can have
package dependency rules like these:
some-package:
Version 4.11_amd64
Depends: X-bin (ver == 2.4, ver > 3.1 && < 3.7) | opengl-dev
Source-Package: some-source
Build-depends: X-devel, (scons-builder (ver >= 3 && ver != 3.3) | basic-make
nvidia-headers:
Provides: opengl-dev
ati-radeon-hd-devel:
Provides: radeon-dev
GNUMake:
Provides: basic-make
BSDMake:
Provides: basic-make
Which says that:
* You can build some-package 4.11_amd64 from some-source-4.11, any
version of X-devel, version 3.x of scons builder (except for 3.3 which
is broken somehow), and that anything providing basic make functionality
is needed, whether it's BSD's make of GNU's.
* However, if you just want to install the binary version, you only
need one of X-bin, or opengl-dev
You could get around the fact that "android-native-devkit" is a whole
bunch of tools and libraries which don't confirm to the package system,
by creating a dummy package requiring android-native-devkit, and saying
that it provides basic-make and opengl-headers, so that the dependencies
all work out. As another example, you could break opengl-dev into API
versions, saying that android-native-devkit provides opengl-dev,
opengl2-dev, and opengl3-dev, but that ati-radeon-hd-dev provides only
opengl-dev, and opengl2-dev.
Then you can say, for example, "get android-native-devkit from here, and
always use the latest, most unstable version, but give me the most
stable versionm of BSDMake, and make sure X-bin is the stable version,
but with the latest security patches".
One thing you can't do (without chroot/jails/containers) is to say,
"Install these packages here, and install version 1.x of packageN here,
with 3.x there, and 2.5 there.". That's pretty important for virtual
hosting, and development, for example.
In short, Rust's package system should probably support:
* Package names, independent of sources
* Parseable versions
* Dependency EXPRESSIONS, including boolean logic, comparison operators,
negation (i.e., none of the packages in this sub-expression are
compatible), etc.
* Virtual packages which include other packages or wrap other packages
* Multiple installation paths, with a list of packages to be installed /
maintained there
* Some way to use different installation paths based on which project
you're in
* Some way to specify the local installation path during development,
the default installation path for public packages, and a way to override
the default installation path for specific sysadmin purposes.
* Some way to specify dependencies on third-party libraries / tools,
from other languages / package managers. I've little idea of to do
about that. Probably just print an error message and quit, to begin with?
--
Lee
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
