I used 'quickpkg' to make binary packages on a system, basically all the packages needed for an 'emerge -ke system', and transferred them to another machine. I started doing the merge, and after a while, portage complained that I needed to run etc-update. While doing so, I found that it was trying to EMPTY the text files in /etc related to these packages. This is either a very very dangerous "feature" or it's a bug. Either way, it's definitely not desirable, and it's undocumented that it will do this. Reproducible: Always Steps to Reproduce: 1. quickpkg something that has an /etc config file. i.e. sysvinit. 2. emerge -k <package> 3. etc-update, and note what it wants done to the config files.
Oh, and if you do accept etc-update's suggested changes unintentionally, it's easy to find out which packages are probably broken by this: Using the md5sum for an empty file, you can find which files are empty, and find what packages own them with portage-utils: cd /etc; find . -type f | xargs md5sum | grep ^d41d8cd9 | cut -d' ' -f 3 | sed 's/^[.]\///' | xargs qfile | cut -d' ' -f 1 | uniq (It has just hit me that I'm a nerd for coming up with the above commands...) and then remerge the ones it lists. Of course, some of these are probably INTENTIONALLY blanked config files, but it can't hurt to remerge them anyway and then be a bit more scrutinizing of the etc-update suggestions.
Did you include config files in the package built by quickpkg? Note the following output for baselayout: # quickpkg baselayout * Building package for sys-apps/baselayout-2.0.1 ... [ ok ] * Excluded config: '/etc/filesystems' * Excluded config: '/etc/hosts' * Excluded config: '/etc/inputrc' * Excluded config: '/etc/issue' * Excluded config: '/etc/issue.logo' * Excluded config: '/etc/modprobe.d/aliases.conf' * Excluded config: '/etc/modprobe.d/i386.conf' * Excluded config: '/etc/networks' * Excluded config: '/etc/profile' * Excluded config: '/etc/protocols' * Excluded config: '/etc/services' * Excluded config: '/etc/shells' * Excluded config: '/etc/sysctl.conf' * Packages now in '/usr/portage/packages': * sys-apps/baselayout-2.0.1: 22.0K * Excluded config files: 13 * See --help if you would like to include config files. I can duplicate this behavior if the config files are not included.
Correct, I apologize for not specifying in the original post. I indeed didn't explicitly _tell_ it to include the config files. However, this is not an excuse for trying to empty config files via etc-update. The cited reason (in documentation) for not including them in the first place is a "security risk", but wouldn't zeroing the config be just as bad? It could render a system inoperable, especially if the files are init scripts.
Historically, the reason for including the empty files was to give a hint to the FEATURES=collision-protect code, so that future merges of the package would not trigger a file collision. However, we now have FEATURES=protect-owned, which is enabled by default, and it gives an error message but does not bail out when such a collision occurs. So, I suppose we can add an option to control the inclusion of zero-byte config files, and disable it by default.
i'm not sure that is any better. if you emerge such a package on a system with say FEATURES=unmerge-orphans, all of the config files will get deleted. perhaps instead of a 0 byte file, you put in a line like: # empty file because --include-config=n when `quickpkg` was used
(In reply to comment #5) > perhaps instead of a 0 byte file, you put in a line like: > # empty file because --include-config=n when `quickpkg` was used That's in svn r15278.
Just coming here from another semi-related bug. $ quickpkg --help --include-unmodified-config=<y|n> include files protected by CONFIG_PROTECT that have not been modified since installation (as a security precaution, default is 'n') Hmm, how are default config files shipped with the package sensitive in any way? Or do I misunderstand the meaning of "modified" in the above?
(In reply to comment #7) > Hmm, how are default config files shipped with the package sensitive in any > way? Or do I misunderstand the meaning of "modified" in the above? You can use --include-config=y to create a binary package containing "sensitive modified" config files. Then if you install the resulting binary package, the "sensitive modified" files are now indistinguishable from "unmodified" config files since they do not differ from the ones listed in /var/db/pkg/*/*/CONTENTS.
This is fixed in 2.1.8 and 2.2_rc64.
