tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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

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
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

Home | Main Index | Thread Index | Old Index