Package "mounting" proposal

[Sven Moritz Hallberg]

Simon Marlow <simonmarhaskell at gmail.com>, 2006-07-24 12.13 +0100:
> >> 1. Add a field to the package description of foo (v1.4, say) that says
> >>    "I'm backwards-compatible with 1.3." When building, this relation
> >>    would have to be inspected to see whether any currently installed
> >>    version of foo satisfies the dependency specified by the mount.
> >> 2. Declare a convention for version numbers to carry compatibility
> >>    information, like the OpenGL standard, for example: If the new
> >>    version is backwards-compatible, only the minor version number
> >>    changes. If it isn't, the major version number must be incremented.
> >
> >I prefer 1. The FSF use 2 for its GNU software and others started with it,
> >too. But after a while most of them tend to increase major numbers. E.g.
> >3.0, 3.11, 95, 98, 2000
> 
> I think we should do (1).

I don't particularly oppose (1) either. I only want to enable fully
automatic satisfaction of dependencies with minimal maintenance overhead
for all parties involved. In an "ideal world", where that means "everyone
will happily follow the convention" in this context, (2) would require a
little less maintenance, but (1) isn't so bad. ;)


> But we should also keep the current mechanism of 
> allowing a package to specify a range of dependencies, the reason being 
> that even when an interface upgrade isn't fully compatible, the package 
> might still work with it, and this is a property of the consuming package, 
> not the package that is depended on.

Valid point. Taken together with your earlier points about keeping the
analogy to module imports, I think we might want something like the
following in the package description:

    import: qualified foo[1.1 - 1.3, 2.3] as baz

I.e.

    - Specify a list of known compatible version ranges.
    - Allow qualified imports with aliasing.

Would we also want unqualified imports with aliasing? The details there are
not so important to me, I think, but I'd like to make one point which I
think is pretty crucial...

IMHO, we should _not_ allow unbounded version ranges to be specified as
compatible. The reason being that such a statement would in general be
false and the build system would not be able to deduce very meaningful
information from it. Again, I'd like to see a system possible which I can
tell "fetch package foo" and it will fetch it and all its dependencies
with a pretty good confidence of everything working fine. If foo depends
on bar and specifies "any version later than 1.1", this dependency will
break at some point. I think we must clearly seperate the two sides:

  1. The author of foo knows some set of versions to be compatible with
     foo.
  2. The author of bar knows, for each version of bar, some set of
     versions it is backwards-compatible with, e.g. "what works with 1.1
     will always also work with 1.2".

Both sides specify their knowledge in their respective package
descriptions and the build system acts accordingly. In the case where it
cannot offer any version of bar that it _knows_ to be compatible with foo,
it could (be instructed to) _attempt_ compilation with whatever it has and
maybe it will work, but it should not blindly do so and possibly fail (as it
would sooner or later if foo could say "I work with everything >=1.1").


Best regards,
Sven