[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 4/16/2013 19:02, Thomas Klausner wrote:
On Tue, Apr 16, 2013 at 06:29:19PM +0200, John Marino wrote:
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.
I am sure it doesn't. I was proposing that it could (and perhaps
should) behave this way, at least optionally. That will require some Mk
However, it sounds like you might be interested in setting
This way, all the ABI dependencies are ignored and only the API
Possibly. I might prefer an automated way of replacing the files from
source just to avoid surprises.
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
I can't point to anything off-hand, I really wasn't looking at them with
this POV. However, could there be case of a library upgrade (new major
number) that resulted in a revbump when the library was backwards
compatible? That would be an example. I also recognize that a bump
will never result in a broken package while the lack of a bump in the
case the library wasn't backwards compatible would and it's easier to
err on the conservative side.
Honestly I think the "make replace" issue is the main one. If that were
fixed, I could live with dependence rebuilds. It's just time (unless I
don't have much, then it's still annoying.)
Main Index |
Thread Index |