Dieter Baron <dillo@danbala.tuwien.ac.at> writes:

>> Perhaps we call this EARLIEST_COMPATIBLE_ABI to emphasize that it should
>> contain the earliest version with which the current version is ABI
>> compatible.
>
>   I don't want to have ABI as part of the variable's name, since it is
> not only about shared library ABI, but also any other backwards
> incompatible change.  EARLIEST_COMPATIBLE_VERSION?

It really is about the broader definition of ABI - if the binary package
is installed, will interacting with it at runtime be ok.  This is shlib
ABI, and also the format of any script interaction.  It's not .h files

EARLIEST_COMPATIBLE_VERSION is fine.

>> I don't see where "depending package does not accept" comes from.  The
>> package is recorded as built against 1.3.2, and when considering 1.4.2
>> we see EARLIEST_COMPATIBLE_ABI is 1.4, and since that's > 1.3.2, it's
>> not usable.
>
>   Yes.  It accepts versions less than EARLIEST_COMPATIBLE_ABI (1.3.2,
> which is less than 1.4), thus it's not usable.

I see what you mean, but I still think "does not accept" is confusing
and that others will have trouble with it.

>>  I see the depending package as simply recording what it was
>> built against, and the rule is that the version of libfoo has to be >=
>> the recorded version, and the EARLIEST_COMPATIBLE_ABI for libfoo has to
>> be <= the recorded version.
>
>   Yes.  Although I don't know if I really want to go from recording
> dependency patterns to just recording the version it was built
> against, as that looses flexibility.  We would have to check wether
> that flexibility is used/needed somewhere in pkgsrc.

I think what we've learned from this exercise is that the notion of
dependency patterns for a binary package is broken.  A particular
version was linked against, and so that version can be used, or any
later version that doesn't break ABI compatibility (more or less by
definition).  Can you give an example of where a pattern would make
sense and the 'record version it was built against' would fail?

>> If you want pkg_add -u to need some sort of forcing flag in the case of
>> a known ABI change, that's fine with me.  The binary version of
>> pkg_rolling-replace will just always use the flag.
>
>   I' okay with it if it requres a forcing flag, but I insist on that
> flag: the user should have to explicitly state that he is okay with
> things getting broken.

Note that the current behavior is that pkg_add -u just proceeds
regardless of ABI compatability issues.  So one option is to leave -u
for that, and have 'pkg_add foo.tgz' do an upgrade if foo is already
installed and the new one is compatible.

I would like to avoid overloading -f with 'skip all checks'.  It would
be nice to be able to skip checks individually so scripts can only force
what they want.  For humans it doesn't matter - they run the command,
read the error, and then run -f.