Subject: Re: png ABI bump - why?
To: Jaromir Dolecek <firstname.lastname@example.org>
From: Todd Vierling <email@example.com>
Date: 04/22/2006 15:47:18
On 4/22/06, Jaromir Dolecek <firstname.lastname@example.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
> 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=
> > 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
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
> 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
> 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 <email@example.com> <firstname.lastname@example.org> <email@example.com>