GMP change
in [Ports]
|
Prev: LUAR BIASA!!! ABSENSI SIDIK JARI HANYA 1, 3 JUTA => LIFETIME WARANTY
Next: portupgrade of gtk-2.18.7_1 failing against cairo-xlib?
From: Andrea Venturoli on 22 Apr 2010 07:22 On 04/22/10 11:36, Luca Pizzamiglio wrote: > Hallo Andrea, > > I've had the same problem using portupgrade and no clean solution found. > > This is the dirty trick I've used: > > pkg_delete -f libgmp4\* > portupgrade -N math/gmp > > BTW, portupgrade with -o doesn't work because now the conflicts is > checked "before" the building process and gmp building fails.. > > Best regards! Thanks, I'm trying this. However, after pkg_delete, I did: # pkgdb -F ---> Checking the package registry database Stale dependency: gcc-4.3.5.20091227 -> libgmp-4.3.2 (math/libgmp4): -> Deleted. (irrelevant) Stale dependency: kdemultimedia-3.5.10_4 -> libgmp-4.3.2 (math/libgmp4): -> Deleted. (irrelevant) Stale dependency: kdeutils-3.5.10_4 -> libgmp-4.3.2 (math/libgmp4): -> Deleted. (irrelevant) Stale dependency: libao-0.8.8_1 -> libgmp-4.3.2 (math/libgmp4): -> Deleted. (irrelevant) Stale dependency: mpfr-2.4.2 -> libgmp-4.3.2 (math/libgmp4): -> Deleted. (irrelevant) Stale dependency: superkaramba-lwp-15.0_5 -> libgmp-4.3.2 (math/libgmp4): -> Deleted. (irrelevant) Stale dependency: vorbis-tools-1.2.0_6,3 -> libgmp-4.3.2 (math/libgmp4): -> Deleted. (irrelevant) Of course, when I later updated one of the above packages, gmp was found missing and got installed, but what really makes me wonder is pkgdb thinking all these dependencies are really irrelevant; this is some behaviour I also recently noticed in other situations and found it strange there too. Any pointer on how pkgdb decides that? bye & Thanks av. _______________________________________________ freebsd-ports(a)freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscribe(a)freebsd.org"
From: Doug Barton on 25 Apr 2010 22:28
On 04/23/10 07:14, jhell wrote: > Doug, > > You mentioned in your reply that portmaster already sets > DISABLE_CONFLICTS=1 for -o in version 2.22. Does it also do this while > the -r flag has been specified and thus enabling that while upgrading > recursively ? or does it drop the DISABLE_CONFLICTS variable after the > port that was specified after the -o flag has been upgraded ? It only does it for -o. hth, Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ _______________________________________________ freebsd-ports(a)freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscribe(a)freebsd.org" |