On 4/22/06, Jaromir Dolecek <jdolecek@netbsd.org> wrote:
> > If part of the downstream png fix is to link against libpng12, then
> > gimp needs an override BUILDLINK_API_DEPENDS.png so that
> > USE_ABI_DEPENDS=3Dno has no effect for gimp.
>
> Do you mean that all the packages in pkgsrc have been changed to
> link against libpng12 instead of libpng, and thus I need to update
> png version in order to be still able to compile stuff from pkgsrc?

No, I specifically mentioned an API dependency override for gimp.  The
BUILDLINK_*_DEPENDS.<pkg> variables can be put into a dependent too,
as they all apply -- thus ensuring that the dependency is at least as
new as is needed for building and running a given package with the
*current* ABI.

> If pkgsrc packages now compile fine with older png, the ABI
> depend on png-1.2.9 should only be forced if png-1.2.9 was
> actually used for compilation

We don't go that granular.  If there is a complete ABI break (all
packages now link against a different LIBNAME.so.N at runtime, whether
LIBNAME and/or N changed), then BUILDLINK_ABI_DEPENDS is bumped for
the purpose of reproduceability.

> > That's fine.  IGNORE_RECOMMENDED=3Dyes (and now USE_ABI_DEPENDS=3Dno) i=
s
> > not exactly a fully supported option, as it's not guaranteed to work.
> > However, pkgsrc *can* be fixed to make it work where it is currently
> > broken, if the brokenness is reported.
>
> I wasn't aware it's officially unsupported. Why it's there at all
> then? It's useless to have known-broken feature in.

It's not known broken.  It's known that if you set it, that you are
*on your own* as far as support for any given problem you may
encounter.

BUILDLINK_ABI_DEPENDS (formerly BUILDLINK_RECOMMENDED) quite
deliberately ensures that, with default options, all packages compile
against a reproduceable ABI.  If you want to be able to use a
*non-current* ABI -- as with packages that satisfy
BUILDLINK_API_DEPENDS but not _ABI_DEPENDS -- then you have to set
USE_ABI_DEPENDS=3Dno under the assumption that you're doing something
not guaranteed by the bulk build system or by official binary
packages.

> Since it's current pkgsrc standard to bump the RECOMMENDED/ABI
> depends each time random pkgsrc package needs the newer version
> or for other random reasons like security issues,

The name was changed specifically to codify that security reasons are
no longer a criterion for bumping BUILDLINK_ABI_DEPENDS.  There are no
other "random pkgsrc package needs" besides ABI changes (and a package
maintainer not completely understanding the purpose of the variable,
as has been a problem in the past).

> > That is NOT, however, a reason to stop bumping BUILDLINK_ABI_DEPENDS,
> > as that is required for default-build reproduceability.
>
> Pardon? So pkgsrc has policy "let's force all pkgsrc users update
> all their packages all the time just because pkgsrc developers
> are lazy to bump depends on packages which actually need it" ?

The ABI changed due to functions being removed from the library, and
we're not supporting a no-longer-current-in-pkgsrc ABI.  You either
rebuild with the newer package, or you venture on your own with
USE_ABI_DEPENDS=3Dno.  You're provided a choice.

I've actually argued the same thing you are trying to say, but then I
ran into problems because I wasn't paying attention to ABI changes.=20
So now I'm quite intimately familiar with why ABI dependency as a
baseline (if it can be avoided by the user's choice) is a very good
idea....

> Default-build reproduceability is certainly not reason to bump
> ABI depends.

Then for what other reason does differences in ABI matter at all?

--
-- Todd Vierling <tv@duh.org> <tv@pobox.com> <todd@vierling.name>