in /var/cache/edb/world I have: =net-mail/postfix-1.1.11-r2 Which has been working up thru postfix-1.1.1-r5 (that is, not updating postfix) However today, 'emerge -pu world' gets me this: Calculating world dependencies ...done! [ebuild U ] net-mail/postfix-1.1.11.20020917 Paul (emerged to most recent stable portage)
*** Bug 14532 has been marked as a duplicate of this bug. ***
The same thing happens on my box: $ grep ghostscript /var/cache/edb/world =app-text/ghostscript-7.05.6-r1 $ emerge world -upv These are the packages that I would merge, in order: Calculating world dependencies ...done! [ebuild UD] app-text/ghostscript-7.05.5 [7.05.6-r1] +X +cups +gnome
Package pins seem to not work very well. In my world file I have: <net-www/apache-2 The system does not have ACCEPT_KEYWORDS="~x86" in /etc/make.conf, i.e. it's using stable x86. When I do a normal update world: # emerge -puv world # system up-to-date, nothing merged If I tell it to allow testing packages: # ACCEPT_KEYWORDS="~x86" emerge -puv world | grep apache [ebuild U ] net-www/apache-1.3.27-r4 [1.3.27-r3] -ipv6 +pam [ebuild U ] net-www/apache-2.0.46 [1.3.27-r3] +berkdb +gdbm +ldap [ebuild U ] dev-php/mod_php-4.3.2-r2 [4.3.1] -X -cjk +crypt -curl -firebird -flash -freetds -gd +gdbm -imap -informix +java +jpeg +ldap -mcal +mysql +nls -oci8 -odbc +pam +pdflib -memlimit -pic +png -postgres -qt +snmp +spell +ssl -tiff +truetype -apache2 Note that is emerging apache twice and upgrading to 2.0.46, and also that -apache2 is in effect. The mod_php dependencies are: DEPEND="${DEPEND} >=net-www/apache-1.3.26-r2 apache2? ( >=net-www/apache-2.0.43-r1 ) " So the -apache2 should make mod_php only require apache-1.3.26-r2 or newer. The other problem is trying to pin down a testing package in a stable setup. If I have in world: >=dev-db/mysql-4 but not dev-php/mod_php, then: # emerge -puv world # up-to-date, have mysql-4.0.13, -r1 is available) This is arguably correct behavior, since the package is ~masked. However, if I add dev-db/mod_php to world: # emerge -puv world | grep mysql [ebuild UD] dev-db/mysql-3.23.56 [4.0.13] -static +readline +innodb +berkdb +tcpd +ssl [ebuild U ] dev-perl/DBD-mysql-2.1027 [2.1013-r1] [ebuild U ] dev-php/mod_php-4.3.2 [4.3.1] -X -cjk +crypt -curl -firebird -flash -freetds -gd +gdbm -imap -informix +java +jpeg +ldap -mcal +mysql +nls -oci8 -odbc +pam +pdflib -memlimit -pic +png -postgres -qt +snmp +spell +ssl -tiff +truetype -apache2 This is the most frustrating Portage/Gentoo bug I know of...
confirmed. I wanted to pin my xfree with =x11-base/xfree-4.2.1-r2 but no luck. As far as I know there is currently no _clean_ and _permanent way to avoid updating of a particular package: - editing the KEYWORDS and "~" the package - editing package.mask both are overwritten by "emerge sync". A quick search in the formums showed various threads suggesting a "--exclude"-feature or something like that -- if the pinning-feature worked as documented this wouldn't be needed.
One thing that may help in recent portage versions is /etc/portage/package.mask, which is a local version of /usr/portage/profiles/package.mask. Older versions had /etc/portage/profiles/package.mask; you might have to try both. Not quite the same as a pin, but it may help in some situations.
*** Bug 20960 has been marked as a duplicate of this bug. ***
My experiences are as follows... in world I first added =sys-devel/gcc-3.2.3-r1 (keep this version) if I set ACCEPT_KEYWORDS="~x86" and do emerge -up world it wants to upgrade to sys-devel/gcc-3.3.1-r1 then I tried this in world file <sys-devel/gcc-3.3 (do not emerge any version 3.3 and higher) now for an interesting twist after emerge -up world it first wants to upgrade to sys-devel/gcc-3.3.1-r1 then later in the same list it wants to upgrade to sys-devel/gcc-3.2.3-r2 TWO entries this is a variation of the upgrade/downgrade loop others have experienced Please notice that gcc-3.2.3-r2 IS following the entry in the world file thus the world file is accessed later on in the upgrade checks. Finally I have >=net-www/galeon-1.3.2 in the same world file and it is being "respected". If I remove that line galeon will be downgrade (expected behavior). Now the only difference between galeon and gcc is I emerged galeon manually and gcc is from a stage 3 tar ball.
In my experience I've decided the world file doesn't work very well for pinning packages, or at least not for packages that are masked. You'll have better luck doing this (I've done it myself for these same packages): /etc/portage/package.mask: =sys-devel/gcc-3.3.1* =dev-libs/openssl-0.9.7* /etc/portage/package.unmask: =net-www/galeon-1.3* /var/cache/edb/world: net-www/galeon (sys-devel/gcc is in the system profile, of course) (Also note that you'll probably need to mask openssl-0.9.7 like I did if you are staying with gcc-3.2.3, or else remove this file if you have it: /usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3/include/openssl/bn.h If you have it, it's probably from openssl-0.9.6 and will break things that call BN_mod, like openssh. See bug #13795. This bug is still in gcc-3.2.3-r3 but they closed the bug anyway. gcc-3.3.1-r1 does it right, but has problems with -fstack-protector.)
you can use /etc/portage/package.[un]mask to create local [un]masks
pinning in world file is now deprecated (dont do it) use /etc/portage to control masking/version sticking