After sync and update today I tried to depclean my machines. Only one succeeded, the others told me: !!! You have no system list. Cannot determine system from world. I wasn't able to detect the source of failure yet. But one thing is clear: depclean checks if syslist is empty. But deep update -- `emerge -Duv system` doesn't and so can't find any package to update even though there are! As of yesterday `emerge -Dup system` returned app-arch/tar to be updated on one of the now failing machines -- so at least on this machine the machanism broke within the last 24 hours. Reproducible: Always Steps to Reproduce: 1. emerge -pv depclean 2. emerge -Dup system Actual Results: emerge -pv depclean tells me there is no system list emerge -Dup system returns very fast and tells me there are no packages to update. Expected Results: emerge -pv depclean should give me a summary of installed packages and maybe a list of packages it would unmerge emerge -Dup system should check, if system needs to be updated.
Don't tell me why but /usr/portage/profiles/base/packages does not exist on the failing machines, it does exist on the machine I sync with. Copying it manually fixes the "no system list" failure. It doesn't change anything with emerge though -- emerge update has to check for a syslist. That's vital.
Caspar, check your machine which serves as your rsync host. In the rsyncd.conf file please remove the exclude lines, OR prefix packages and distfiles with /: exclude = /packages /distfiles ^^^ like that. But, portage already natively does NOT sync those directories anyway, so even removing that line entirely will be fine. Restart your rsync server, attempt emerge sync. *** This bug has been marked as a duplicate of 86131 ***
I don't agree with the decision to mark it a duplicate. I reported a bug that emerge does not properly check for empty syslist. How and why syslist is empty is not important at that point.
Portage's behaviour in regards to emerge -pv depclean and emerge -Dup system is valid. You lack a system list on the client boxes cause of the bug this is duped on, so their isn't anything really to report.
It is possible for syslist to be empty. If this is the case some functions work differently, eg update doesn't check for system updates. And you say it's not a bug if a function doesn't perform its intended functionality? That's ridiculous. This was my last bug report on Gentoo. Bye...
the 'system' list is stored in rsync the list on your system was empty portage checked for updates in the empty list and, finding none, aborted
That's wrong -- depclean checks for an empty syslist. Running depclean aborted noticing me about this situation. That behaviour is fine. Running update was just faster but its' output was the normal one telling me there were no updates. And this is plain wrong. It did a check for the syslist content but not for the system. Normally syslist represents the system but in this situation it didn't. And syslist can only be empty if there is a failure within the system, not catching it is a bug. The only reason I got notion of the missing packages file within hours was only because I tried to do a depclean. I don't know how often you perform that on your system.
Depclean of *course* checks for empty syslist. Else it could potentially remove all packages on a system. If you've either via a bug, or via your own custom profile ixnaying the syslist, it's not portages job to go rooting through each profile, trying to verify that there is in fact a set of atom that 'system'. So no, it's not 'wrong'. Quite likely it did no such check. Just grabbed the syslist, no nodes to work on, ok, user is a bit whacky, no work to do thus I exit. Re: depclean I don't use it. It has known flaws I don't care to deal with (whether -p, or being dumb and letting it actually do it's thing). I'm not really understanding the continuing push from you on this.
