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

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

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

Home | Main Index | Thread Index | Old Index