| 1 |
Am 15.08.2011 20:02, schrieb Alan McKinnon: |
| 2 |
|
| 3 |
> It's not a bug, portage is doing what it should. |
| 4 |
> |
| 5 |
> In the first case portage will try upgrade all packages to the latest |
| 6 |
> version. It sees that you asked it to try autounmask stuff, so it |
| 7 |
> wants to override your local mask for ExtUtils-ParseXS. |
| 8 |
|
| 9 |
I don't asked portage to autounmask anything, that is a feature of |
| 10 |
portage-2.2 and should normaly only fire when there is a need to unmask |
| 11 |
(or change USE or change keyword) anything to fullfill the needs of the |
| 12 |
packages to be installed or updated. |
| 13 |
|
| 14 |
Else it would tell anyone on stable who use portage-2.2 to change to |
| 15 |
~unstable because there is newer stuff to install. I have a large amount |
| 16 |
on packages that have newer versions that are masked and autounmask |
| 17 |
doesn't ask me to install them only because they are newer. |
| 18 |
|
| 19 |
> In the second case you have told portage to upgrade system and world |
| 20 |
> but to leave masking well enough alone. As your current installed |
| 21 |
> version of ExtUtils-ParseXS satisfies all needs, it makes no effort to |
| 22 |
> try and upgrade it. |
| 23 |
|
| 24 |
I think that you not really know what the autounmask-feature of |
| 25 |
portage-2.2 is all about. |
| 26 |
|
| 27 |
Normally it does something like this: |
| 28 |
|
| 29 |
emerge =perl-core/ExtUtils-ParseXS-3.20.0 -vp |
| 30 |
|
| 31 |
These are the packages that would be merged, in order: |
| 32 |
|
| 33 |
Calculating dependencies ... done! |
| 34 |
[ebuild U ] perl-core/ExtUtils-ParseXS-3.20.0 [2.22.06] 0 kB |
| 35 |
|
| 36 |
Total: 1 package (1 upgrade), Size of downloads: 0 kB |
| 37 |
|
| 38 |
The following keyword changes are necessary to proceed: |
| 39 |
#required by =perl-core/ExtUtils-ParseXS-3.20.0 (argument) |
| 40 |
>=perl-core/ExtUtils-ParseXS-3.20.0 ~amd64 |
| 41 |
|
| 42 |
NOTE: This --autounmask behavior can be disabled by setting |
| 43 |
EMERGE_DEFAULT_OPTS="--autounmask=n" in make.conf. |
| 44 |
|
| 45 |
without it would look like this: |
| 46 |
|
| 47 |
EMERGE_DEFAULT_OPTS="--autounmask=n" emerge |
| 48 |
=perl-core/ExtUtils-ParseXS-3.20.0 -vp |
| 49 |
|
| 50 |
These are the packages that would be merged, in order: |
| 51 |
|
| 52 |
Calculating dependencies ... done! |
| 53 |
|
| 54 |
!!! All ebuilds that could satisfy "=perl-core/ExtUtils-ParseXS-3.20.0" |
| 55 |
have been masked. |
| 56 |
!!! One of the following masked packages is required to complete your |
| 57 |
request: |
| 58 |
- perl-core/ExtUtils-ParseXS-3.20.0::gentoo (masked by: ~amd64 keyword) |
| 59 |
|
| 60 |
For more information, see the MASKED PACKAGES section in the emerge |
| 61 |
man page or refer to the Gentoo Handbook. |
| 62 |
|
| 63 |
It is just a other way to display what is needed to be done. If |
| 64 |
autounmask fires portage should throw an error too if trying the same |
| 65 |
thing again with autounmask=n. But here it doesn't. It tells me to |
| 66 |
unmaks without any need. |
| 67 |
|
| 68 |
> The trick to working with autounmask is to realise that it is stupid |
| 69 |
> software, it cannot possibly know what you want or intend. So it tries |
| 70 |
> a blanket approach for the most part. If you have more complex masking |
| 71 |
> than just stable/unstable statistically it will be wrong far more |
| 72 |
> often than it is right. |
| 73 |
|
| 74 |
If there is a package version masked and nothing needs that version then |
| 75 |
autounmask should not fire. It should leave that alone. |
| 76 |
|
| 77 |
For me it still looks like a bug. |
| 78 |
|
| 79 |
Greetings |
| 80 |
|
| 81 |
Sebastian |
Archives