| 1 |
Here we go again. All week I've been trying to update @world. I'm trying |
| 2 |
to troubleshoot a portage bug[0], deal with portage taking forever to |
| 3 |
fail, and now I've got to deal with the fact that someone was too clever |
| 4 |
to follow the PMS and replaced virtual/pam with sys-libs/pam across the |
| 5 |
entire tree (and immediately masked the package that we all have |
| 6 |
installed) without creating any new revisions. |
| 7 |
|
| 8 |
Thanks to the aforementioned portage bug, I can't follow the non-PMS |
| 9 |
suggestion to update everything with --changed-deps. So I either have to |
| 10 |
live with the fact that I have a masked package (virtual/pam) installed |
| 11 |
-- which pisses portage off and makes it impossible to troubleshoot my |
| 12 |
dependency resolution problem -- or try to uninstall it and then resolve |
| 13 |
the rebuilds myself. This is how that goes: |
| 14 |
|
| 15 |
$ time emerge -puDN --tree @world |
| 16 |
|
| 17 |
These are the packages that would be merged, in reverse order: |
| 18 |
|
| 19 |
Calculating dependencies... done! |
| 20 |
[nomerge ] net-print/cups-2.2.12 |
| 21 |
[ebuild N #] virtual/pam-0-r1 |
| 22 |
|
| 23 |
The following mask changes are necessary to proceed: |
| 24 |
(see "package.unmask" in the portage(5) man page for more details) |
| 25 |
... |
| 26 |
=virtual/pam-0-r1 |
| 27 |
|
| 28 |
NOTE: The --autounmask-keep-masks option will prevent emerge |
| 29 |
from creating package.unmask or ** keyword changes. |
| 30 |
|
| 31 |
* In order to avoid wasting time, backtracking has terminated early |
| 32 |
* due to the above autounmask change(s). The --autounmask-backtrack=y |
| 33 |
* option can be used to force further backtracking, but there is no |
| 34 |
* guarantee that it will produce a solution. |
| 35 |
|
| 36 |
real 4m37.909s |
| 37 |
user 4m35.287s |
| 38 |
sys 0m1.437s |
| 39 |
|
| 40 |
|
| 41 |
Now I re-emerge cups, and try again. Then net-fs/samba fails. Then |
| 42 |
sys-libs/libcap fails. Then sys-apps/shadow fails. Then |
| 43 |
x11-themes/slim-themes fails. And so on. These are all things that I |
| 44 |
have to sit in front of the keyboard for 4m37.909s, time and time again |
| 45 |
to deal with, all because RDEPEND was changed without a new revision. |
| 46 |
|
| 47 |
That's it, that's all I did for Gentoo today. I started out at 8am |
| 48 |
trying to fix two bugs, and I spent all of my free time today unfucking |
| 49 |
my system. Now it's 6pm and I'm out of time with nothing accomplished. I |
| 50 |
haven't even found all of the packages that I need to rebuild yet, so |
| 51 |
this is where I'll start again tomorrow, too. |
| 52 |
|
| 53 |
And it's not like this is a rare problem. Please, just follow the damned |
| 54 |
PMS and make a new revision when you change dependencies. It's not much |
| 55 |
harder to do things right, so cutting corners and wasting my whole day |
| 56 |
is pretty selfish. And as a bonus, the people who don't use portage |
| 57 |
won't think you're an asshole for telling them to fix the problem by |
| 58 |
using portage. |
| 59 |
|
| 60 |
|
| 61 |
[0] https://bugs.gentoo.org/698232 |
Archives