Subject: Re: CVS commit: pkgsrc/converters/libiconv
To: Thomas Klausner <email@example.com>
From: Frederick Bruckman <firstname.lastname@example.org>
Date: 08/31/2002 09:40:22
On Sat, 31 Aug 2002, Thomas Klausner wrote:
> On Sat, Aug 31, 2002 at 12:09:32AM -0500, Frederick Bruckman wrote:
> > > Modified Files:
> > > pkgsrc/converters/libiconv: Makefile PLIST distinfo
> > > pkgsrc/converters/libiconv/patches: patch-ab
> > > Removed Files:
> > > pkgsrc/converters/libiconv/patches: patch-aa
> > This has a shared library major bump, but no change to buildlink
> > DEPENDS or any version bumps. If not fixed, this is ultimately
> > going to cause lossage for 1.6 binary packages of, for example,
> > "evolution" or "gnome-utils".
> While you are correct about the first part, this change was after the
> 1.6 branch.
It *will* cause problems, because of the unified 1.6 packages -- as
soon as anyone uploads a package for current libiconv, all packages
which were built against the 1.6 tagged libiconv will be broken for
"pkg_add" over the network.
> I still think that updating all PKGREVISIONs of packages that depend
> on a package every time that there is a major bump is very
> annoying. Is there no other way?
We've been over this before. Of all the alternatives, this one seems
to work. How many complaints did we get from users regarding "png"?
Surprisingly few, considering the burden it must have imposed on
users. The main reason being, I suggest, is that when all the work is
done, you have packages that work, whereas otherwise, they'd go to all
the trouble to deinstall their old packages only to find that packages
won't reinstall, or dump core after they do.
The point (moral?) is that hiding dependencies in buildlink.mk's
doesn't help. As of April this year, there were 63 packages that
depend on libiconv-1.7. The majority of these have no run-time
dependency on libiconv's shared library, but you can't know that
unless you build them. When these are affected by bumping buildlink
DEPENDS and PKGREVISIONS, they're considered "acceptable casualties".
The right way to do this would be to express DEPENDS only in the
Makefiles of packages that care about the version of the requirement
(mostly packages which contain run-time depends on the shared library,
but there may be a few other cases.) Now all you have to do is "grep
-l converters/libiconv */*/Makefile*" to develop a list of files in
which to bump the DEPENDS, PKGREVISION, and commit. With the current
situation, developers are updating shared library packages without
even checking that the dependents still build, because they can't
readily figure out what the dependents are.