Re: revbumps [was Re: suggestion: Host fly-off between pkgin and nih and subsequent official integration]

[Thomas Klausner <wiz%NetBSD.org@localhost>]

On Tue, Apr 16, 2013 at 06:29:19PM +0200, John Marino wrote:
> 1) I really have been focusing on the source build scenario and not
> binary packages.  These revbumps absolutely make building from
> source in place unbearable.  If functionality was added to pkgsrc
> that would do "make replace" automatically instead of "make install"
> when a package was already on the system, this would basically
> address my complaint.  I don't even think it would be that hard to
> technically do.
> 
> So I just want to cd to a directory and type "make install".  I
> don't care if it has to rebuild and replace 20 dependencies first as
> I don't have to individually "make replace" all 20 individually.
> Surely you know what I'm talking about?

Yes. I'm not sure that what you want already exists; perhaps
DEPENDS_TARGET can be set in some way to make this work.

However, it sounds like you might be interested in setting
USE_ABI_DEPENDS=no
This way, all the ABI dependencies are ignored and only the API
dependencies count.

You should, of course, never make such a set of binary packages
available, since it's in an inconsistent state, depending on your
exact update steps.

> 2) Is the png 1.5/1.6 example actually feasible?  with a major api
> change, all the packages that depend on png would have to be
> replaced.

I think it would be. If you don't need a version of package that was
released after the bump, but just want any e.g. gimp installed, the
tools could install one that was linked against png-1.5.

> In any case, I made a specific exception for api changes
> as the necessity is clear.  I am just not sure that all the revbumps
> fit this use case.

I don't think we do recursive PKGREVISION bumps just for the fun of it
(I'm sure I don't). What particular bumps do you think were
unnecessary?
 Thomas