tech-pkg archive

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

Re: CVS commit: pkgsrc/mk/flavor/pkg



Joerg Sonnenberger <joerg%britannica.bec.de@localhost> writes:

> On Sun, Jun 13, 2010 at 11:34:00AM +0200, Tobias Nygren wrote:
>> On the other hand, I don't think sprinkling -f on the problem is the
>> right fix either.
>
> It is not the right fix. From the recent feedback in #pkgsrc, I am
> starting to wonder if the change was tested at all, given the rather
> obvious breakage it creates.

I did test it, and it successfully finished the rest of pkg_rr from when
my run failed due to osabi.  But I have today noticed that the use of -f
causes pkg_add to behave differently rather than just overriding checks
in some cases, and I agree not using -f is the way to go - see my note
adding the -D option which only avoids the one dependency check.

>> The osabi dummy package itself seems to me like a rather kludgy solution
>> to a subset of a difficult problem. From the perspective of updating
>> it causes more problems than it solves. Besides, when you try to install
>> a package build for a different OS release you already get a warning
>> from the tools.
>
> osabi itself is OK.

I agree.  The osabi package solves a real problem, which is knowing that
a package should be rebuilt because the OS ABI changed.  The current
discussion is only about the way pkg_rr people deal with causing that
update to happen, not whether causing updates is a good thing - I think
we all agree that's fine.

> I am starting to wonder if the forced dependency is
> needed at all -- at least pkg_rr should handle it correctly without
> that.

Without the forced dependency (by which I assume you mean "a package
depends on one specific version of osabi"), then I think pkg_rr works
fine.

In general, there can be these specific dependencies, so I think the -D
flag (named whatever) is needed.  If there aren't any specific
dependencies, it will have no effect.  And it would only be exercised
when called by make replace, so it seems like the smallest change
feasible.


I think a lot of the complexity we are dealing with arises from
supporting both source builds and binary builds.  For source builds, the
exact/forced dependency is not helpful.  But for binary builds, it
probably makes a lot of sense.  That's why I wasn't complaining about
exact dependencies existing - I just want make replace to not get
stopped by them, and given that it continues, to do that in a way that
has as little other behavior change as possible

Attachment: pgpLs2EmEiJWd.pgp
Description: PGP signature



Home | Main Index | Thread Index | Old Index