A faulty atom was checked into Q4-2011 today, which caused Portage to prompty abort any of its actions. I was confronted with this myself, and saw reports from others in IRC. Because it's hard for users to work around this, I think Portage should just warn about these failures, but continue nevertheless. It's not the user's fault someone committed a faulty atom. % emerge -1 groff Performing Global Updates: (Could take a couple of minutes if you have a lot of binary packages.) .='update pass' *='binary update' #='/var/db update' @='/var/db move' s='/var/db SLOT move' %='binary move' S='binary SLOT move' p='update /etc/portage/package.*' /net/amun/export/scratch0/gentoo/prefix-overlay-rsync/rsync1a/profiles/updates/3Q-2011.......................... /net/amun/export/scratch0/gentoo/prefix-overlay-rsync/rsync1a/profiles/updates/4Q-2011...... ERROR: Malformed update entry 'move dev-php5/dev-php5/pecl-ssh2 dev-php/dev-php5/pecl-ssh2' Traceback (most recent call last): File "/Library/Gentoo/usr/bin/emerge", line 44, in <module> retval = emerge_main() File "/Library/Gentoo/usr/lib/portage/pym/_emerge/main.py", line 1617, in emerge_main _global_updates(trees, mtimedb["updates"], quiet=("--quiet" in myopts)): File "/Library/Gentoo/usr/lib/portage/pym/portage/_global_updates.py", line 160, in _global_updates moves = vardb.move_ent(update_cmd, repo_match=repo_match) File "/Library/Gentoo/usr/lib/portage/pym/portage/dbapi/vartree.py", line 314, in move_ent origmatches = self.match(origcp, use_cache=0) File "/Library/Gentoo/usr/lib/portage/pym/portage/dbapi/vartree.py", line 488, in match origdep, mydb=self, use_cache=use_cache, settings=self.settings) File "/Library/Gentoo/usr/lib/portage/pym/portage/dbapi/dep_expand.py", line 33, in dep_expand mydep = Atom(mydep, allow_repo=True) File "/Library/Gentoo/usr/lib/portage/pym/portage/dep/__init__.py", line 1103, in __init__ raise InvalidAtom(self) InvalidAtom: dev-php5/dev-php5/pecl-ssh2
*** Bug 388185 has been marked as a duplicate of this bug. ***
*** Bug 388191 has been marked as a duplicate of this bug. ***
Continuing poses the problem that ebuilds might already depend on the moved package, which in turn results in strange failures later on.
Then maybe rsync0 should refuse to update anything in this case? (and send nasty complaints somewhere)
(In reply to comment #4) > Then maybe rsync0 should refuse to update anything in this case? (and send > nasty complaints somewhere) That's one thing. What about teaching repoman to do commits in the profiles/ dir?
I just had exactly the error described above, and I don't quite know how to proceed now. It seems quite obvious that the incriminating line in /usr/portage/profiles/updates/Q4-2011: move dev-php5/dev-php5/pecl-ssh2 dev-php/dev-php5/pecl-ssh2 should be move dev-php5/pecl-ssh2 dev-php/pecl-ssh2 Hmm. Probably, that is. (I'm a bit less sure now.) But is this any way to go, editing Q4-2011 by hand and then proceed? Or is it wiser to just wait until it has been fixed officially? Thanks very much in advance, and best regards, Florian
*** Bug 388197 has been marked as a duplicate of this bug. ***
I'm not sure the "fix" is already on the rsync-slaves, but does emerge --sync still work for you? Or does that abort as well? If so, just remove the faulty line which you identified yourself already: move dev-php5/dev-php5/pecl-ssh2 dev-php/dev-php5/pecl-ssh2
The problem is that if users have a tree with the malformed entry, they can no longer --sync. I see no reason for portage to update profiles when emerge --sync is called. Would it be possible to alter the portage behavior so it does not perform profile updates when emerge --sync it called. This should prevent similar situations in the future
*** Bug 388201 has been marked as a duplicate of this bug. ***
For those who can't sync: emerge --sync --package-moves=n.
(In reply to comment #11) > For those who can't sync: emerge --sync --package-moves=n. as a temporary work around - yes - otherwise comment #9 points to the right direction
Synced ebuilds will already have dependencies on the moved packages, which means packages should be moved right after sync. The solution to the problem is to prevent the distribution of broken updates.
(In reply to comment #13) > Synced ebuilds will already have dependencies on the moved packages, which > means packages should be moved right after sync. > > The solution to the problem is to prevent the distribution of broken updates. So? The profile/update will run when you call emerge without --sync. What is the problem to perform the profile update when the user tried to invokes emerge != --sync? What is the reasoning to perform profile updates after emerge --sync?
This is fixed in git: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=a3005f69ba99d0e882da44716e3743737e6e4987 (In reply to comment #14) > So? The profile/update will run when you call emerge without --sync. What is > the problem to perform the profile update when the user tried to invokes emerge > != --sync? Suppose that you sync and then try to run an emerge --pretend command as a non-root user. The dependency calculation will not behave correctly, because the installed packages have not been moved will not satisfy the dependencies that they are supposed to satisfy. > What is the reasoning to perform profile updates after emerge > --sync? So that the installed package state is brought into sync with the new tree. If you don't want that for some reason, simply use emerge --sync --package-moves=n and you'll get what you want.
can we prevent this from happening again somehow?
(In reply to comment #16) > can we prevent this from happening again somehow? I think the patch that's in git is good enough. Adding repoman support to check the updates would be a nice enhancement, but isn't as critical as the parse_updates fix that's in git.
Tests are in git now too: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=32282d6a5105ebcd0f5ed0229803ec194025f6d6
This is fixed in 2.1.10.31 and 2.2.0_alpha71.
