Subject: Re: CVS commit: pkgsrc/devel/automake
To: None <hubertf@netbsd.org>
From: Robert Elz <kre@munnari.OZ.AU>
List: tech-pkg
Date: 08/27/2001 18:50:03
    Date:        Mon, 27 Aug 2001 14:04:23 +0300 (EEST)
    From:        Hubert Feyrer <hubertf@netbsd.org>
    Message-ID:  <20010827110423.A2513B004@cvs.netbsd.org>

  | fix dependency in automake after autoconf upgrade
  | Noted by Martti Kuparinen <martti.kuparinen@iki.fi> in PR 13792

how can that possibly be the right thing to do?   If automake worked
with autoconf 2.13 before autoconf was upgraded, it will still work
with autoconf 2.13 after autoconf was upgraded, surely.

That is, if I had an older autoconf installed, and now want to install
automake, why do I have to upgrade autoconf now?  (As opposed to why
I might want to for some other reason).

I'd suggest backing out that change, it looks totally wrong, dependancies
should only ever be updated when something about the dependant package
requires a new version (or has only ever been tested on a new version)
of the dependancy.  That clearly isn't what happened here.

This is also what I don't like about all the buildlink stuff ... just
by upgrading the default version in the buildlink file, all the packages that
used to depend upon an old version now depend upon a newer one, without
needing to at all.   I'd suggest deleting the default version stuff from
the buildlink files, and requiring packages to explicitly say which version
they need, rather than just "whatever is current".

eg: I upgraded xfig recently, that wanted me to upgrade libpng, which was
going to require that half the packages I hd installed (including kde2)
be upgraded.   Of course, xfig didn't really need a newer version of png
than I had installed, and fixing its Makefile (and transfig) to be happy
with what I had installed made me much happier indeed.

kre