On Tue, Jul 31, 2007 at 10:23:13AM -0400, Greg Troxel wrote:
> So what happens if a package can be built with 1.4 or 1.4.1, and has an
> autoconf test to use the new procedure in 1.4.1.  Is it marked as
> depending on >= 1.4.1 because it was built that way, and we don't have a
> way to record that 1.4.1's ABI might or might not be different from 1.4,
> just a way to say it's compatible?  (so it's like a shlib minor version
> increase).  That binary package shouldn't be used with 1.4.

  Yes, I think requiring at least the version a package was built
against is correct, for the reason you noted above: A program is
guaranteed to run with a library with a higher minor number than it
was linked against, but it is not guaranteed to work with a lower
version.


> >   We could also go the way you suggested:
> >
> >   In the depending package: DEPENDS=foo>1.4.2, ABI.foo=1.4
> >
> >   In the dependency: ABI=1.5, VERSION=1.5.2
> 
> In all these, do you mean >= ?
>
> This seems cleaner, and lets ABI.foo and DEPENDS.foo have different
> values, which solvess the minor version problem.

  I think you misunderstood my proposal.  I'll try to explain in more
detail:

  Besides a version number, each package can set the variable
INCOMPATIBLE_BEFORE which states that the current version of the
package is incompatible with versions before this.  If this variable
is not set, it is presumed to be backwards compatible to all prior
versions.

  Now when checking wether a dependency is usable, we check that the
dependency pattern is fulfilled (as we do now), but in addition we
check that the depending package does not accept a version earlier
than the dependency's INCOMPATIBLE_BEFORE, as that would mean it was
built against an incompatible earlier version.

  So, to give an example: we have four packages:

  package aaa: DEPENDS += bbb>=1.7
               DEPENDS += ccc>=1.4.2
               DEPENDS += ddd>=2.2
  package bbb: PKGNAME = bbb-1.8
  package ccc: PKGNAME = ccc-1.5.6nb2
               INCOMPATIBLE_BEFORE = 1.5.6nb1
  package ddd: PKGNAME = ddd-2.3
               INCOMPATIBLE_BEFORE = 2.0

  When installing aaa, each of its dependencies is checked:

  bbb: bbb-1.8 satisfies bbb>=1.7; since bbb doesn't have
       INCOMPATIBLE_BEFORE set, we are done: bbb is usable.

  ccc: ccc-1.5.6nb2 satisfies ccc>=1.4.2; but ccc is incompatible with
       versions before 1.5.6nb1, and aaa can use 1.4.2, so ccc is *not*
       usable.

  ddd: ddd-2.3 satisfies ddd>=2.2; ddd is compatible back to 2.0, and
       aaa can use 2.2, so ddd is usable.

[storing the abi version for each dependency]
> It's only a few bytes, and I suspect this is going to be hard enough to
> get truly right that choosing simpler and easier over space-efficient
> will turn out better.

  Agreed.  However, I don't think your approach is simpler.

> With this, if ABI values are equal during make replace or pkg_add -u,
> then unsafe_depends doesn't need to be set.

  [Assuming ABI value is basically the same as INCOMPATIBLE_BEFORE.]

  If the ABI values are not the same, the package is known to break
compatibility (at least for some dependencies).  In that case, pkg_add -u
should refuse to replace the package.  That is the whole point of the
exercise.

> Will ABI default to VERSION if unset?  Or '0', meaning that it's
> presumed not to change if we don't set it.

  '0', see above.

> So I can see your proposal as working, even though it doesn't have a way
> to record the equivalent of increases in shlib minor version.

  Why would you want to record a shlib minor version bump. What would
you do with that information?

>  Above I
> am essentially proposing that we presume that this changes with every
> version change, or maybe every upstream change but not nb change.  I am
> slightly nervous about these broad presumptions for which I'm sure we'll
> find exceptions.

  That would mean that you can replace a package only with the same
version.  That doesn't sound useful.  (Also, an nb bump could break
backwards compatibility.)


> It would be cool if there were some PKG_DEVELOPER sort of tool that
> could automatically notice shlib major bumps at update time, and warn if
> ABI doesn't change.

  Indeed.

					yours,
					dillo