| 1 |
On 12/18/19 6:28 PM, Michael Orlitzky wrote: |
| 2 |
> |
| 3 |
> This *does* happen if you mask virtual/emacs. It *could* happen if you |
| 4 |
> delete it. |
| 5 |
> |
| 6 |
|
| 7 |
I tested this out. |
| 8 |
|
| 9 |
Portage seems OK with the missing dependency, but for the overall plan |
| 10 |
to work, you have to wait a long time before deleting virtual/emacs; |
| 11 |
otherwise the upgrade path is broken. With virtual/emacs-26 installed |
| 12 |
and "old" copies of the elisp ebuilds installed, you get unsatisfied |
| 13 |
dependencies switching from emacs-vcs to a live slot of emacs. Everyone |
| 14 |
in that situation must update to virtual/emacs-26-r1, which they can't |
| 15 |
do after you delete it. |
| 16 |
|
| 17 |
And of course you can't mask virtual/emacs in the meantime, because that |
| 18 |
does kill the PM. |
| 19 |
|
| 20 |
New revisions would still be the sane solution, now and in the future, |
| 21 |
because they don't require investigative journalism to uncover exactly |
| 22 |
what might go wrong when we bend the rules /this time/. They also don't |
| 23 |
impose a cutoff date after which upgrading users are screwed. You just |
| 24 |
automate the revbumps, commit them all at once, and make a pull request |
| 25 |
against CI to verify that nothing is too borked. |
Archives