binary updates skipped due to a dependency conflct

[pjp]

I thought python was resolved, but at this point, I have no idea. The emerge didn't last long failing with ACCESS VIOLATION (seemingly on everything once it started). Haven't seen those in a long time, so will have to dig around.

EDIT:

Not too bad if a bit scary.

[pjp]

So I think acpid and eudev were the only failures. acpid due to my kernel sources, not sure about eudev.

However, this is "amusing". Re-running the upgrade command:

[Hu]

quickpkg is dangerous to use for anything other than rolling a system back to its own earlier state, in my opinion. You should instead use FEATURES=buildpkg, which will get you a more accurate snapshot of the package as it was initially installed. The --include-config option on quickpkg was made with good intentions, but in the general case, it's fundamentally impossible to get right, in my opinion. Either you set =n, don't bring across the package's configuration files, and hope that the user overrides the stubs with working ones, or you set =y, bring across the package's configuration files, and hope you don't inherit local administrator changes that shouldn't go across. In the worst case, you might quickpkg a file where some of its configuration files are actually security-sensitive (either directly secret, or read by a process that makes security decisions, like sshd/pam) and unintentionally propagate those to a new system where, had you known, you would have configured the new system differently.

I would grep your CONFIG_PROTECT'd directories for other files with that comment, and update them from good copies.

[pjp]

/etc has 66, so yeah. And I don't often reboot, so now I'm extremely nervous about possible 'non generic' configs. I'll probably work on that next.

As far as I know, I'm only using buildpkg. Or at least it is in FEATURES, and I don't recall ever intentionally using quickpkg. I'll see if I can find a reference. I interpreted the message to be part of buildpkg. I thought buildpkg was a feature, and presumed, having heard of the quickpkg tool, that it was used.

From the chroot:

[Hu]

My understanding is that FEATURES=buildpkg causes Portage to save aside a tbz2 file after src_install runs, and that the saved file is the same set of files that ebuild package qmerge then writes to the filesystem. Thus, these files are never drawn from your filesystem, except where strange ebuilds copied from your filesystem to create files that src_install wrote to $DESTDIR.

quickpkg, on the other hand, is specifically for archiving files from your live filesystem, and is roughly equivalent (though with some special metadata and handling) to tar -c --no-recursion -f package.tbz2 $(equery files category/package-version). That special handling includes the CONFIG_PROTECT mangling you saw, and producing metadata Portage can use to populate /var/db/pkg on the receiver and to manage dependencies.

The two approaches both produce tbz2 files, but as far as I know, neither is implemented in terms of the other.

The client probably just needs to reinstall those virtuals from updated binary packages.

[pjp]

If packages created by quickpkg caused those files to be overwritten, then I still need to discover how or why that happened. I don't believe I have ever used quickpkg. And it wasn't until this thread that I learned packages were called (by 'file') "Gentoo binary package (XPAK)" and how to extract them. All packages are reported as that type on both the client and chroot, so that doesn't function as an identifier (normal vs. potential problem package).

[pjp]

I restored the appropriate /etc/portage directory and reinstalled man-db (emerge -avK man-db) as it was one of the packages with an empty file due to quickpkg.

The file didn't overwrite this time, but it did create two ._cfg entries, /etc/._cfg0000_man_db.conf and /etc/cron.daily/._cfg0000_man-db. So maybe something happened to CONFIG_PROTECT first.

EDIT:

Rebuilt the man-db package in the chroot. Removed it from the client and ensured it downloaded the new package. The package still contains the "empty because" message instead of the actual content.
_________________
Quis separabit? Quo animo?

[pjp]

I guess this is mostly, sort of, kind of resolved. I still see similar issues, but not to the same degree.

[Aiken]

My 1st thought is on the build server rebuild the x11-drivers/ listed so you have binary packages depending for the newer X. Then make sure the client machine does not have any old binary packages hidden somewhere. I am reading that as X has been updated but the binary packages the client is finding have not been compiled against the new X yet.

Early on I was allowing client machines to build their own packages if the build server did not have them but I had problems. I was easier forcing build server only for compiling. The only exception I had previously made to this was machines with older nvidia cards which needed an older driver. Since then I have moved to if the current driver does not support it then that machine can use nouveau.

Have found cleaning up keywords can cause similar looking problems. Encountered that a few days ago after using eix-test-obsolete to clean up my keywords list. Had several packages where I had keyworded a particular version that are now stable. I put it down to the package info and tree + keywords no longer matching. Had problems until those packages were recompiled even though the only thing changed was removing the now redundant entry from keywords.

Finding the build server does need maintenance but with it currently servicing 3 desktops, 2 vm and 4 laptops it is still preferable to each of those machines building their own images. For me the build server host is an i7-3770 with a pair of i7-7700k + distcc helping it.
_________________
Beware the grue.

[pjp]