CRUX

Hi teodor,

I can reproduce that. However, is there a reason why you would change UPGRADE (default) to INSTALL in the first place?

"man 8 pkgadd" clears up the difference between the two options. Is this really a bug, or a misconception?

It is definitely a bug. If a file exists in a directory for some reason, it shouldn't be deleted! It erases your file, you lost your data. It even does not creates new nor in /etc/ nor in /var/lib/pkg/rejected/!

For example, use case is when you roll new core in --install-root=/dir/, then you run a script, which migrates all config files from one system to another, then you chroot into new core and proceed installing remaining ports in the new system. My 'mig' script copies all configs from a custom list from origin directory to destination, so new core gets configs for all programs, even those, which is not yet present in the new system.

Well, okay. Given the fact that it drops existing configs might be undesired behaviour.
I have to say that I have a rather expansive pkgadd.conf on my systems tailored to my needs, but it always uses UPGRADE directives, never INSTALL..

Anyway, feel free to propose a patch for it. I'll need a few months before I can dive into that kind of work with CRUX because of other personal projects that are more important right now.

I haven't been able to reproduce this bug.

1. I mounted an older CRUX installation at /mnt, then appended to the end of /mnt/etc/pkgadd.conf the rule from the original bug report.
2. I rebuilt pkgadd after commenting out CXXFLAGS += -NDEBUG, then put the resulting binary in a separate directory and prepended the directory to root's $PATH.
2. I tried both `pkgadd --root /mnt `, and pkgadd after chrooting to /mnt.
3. In both cases the installation proceeded without erasing any of the existing content in /mnt/etc.
4. The debug version didn't reveal any suspiciously-large sets of regex matches under "Install set" or "Non-Install set". The strace never showed a search of the filesystem to determine files that should be removed upon an INSTALL event.

Was this bug silently fixed in the months since the original report? If it's no longer happening, this issue should be closed. I've been searching up and down pkgadd.cc and pkgutils.cc, only ever finding iterators that go through the package archive to build the keep_list and non_install_list. Even when I manually created a file in /mnt/etc that would have been clobbered by the package footprint, the installation proceeded without destroying that file. I admit I might lack the imagination to see how unlink() would ever be called on a file unrelated to the package (either through its archive contents, or through /var/lib/pkg/db). But maybe some gcc voodoo was translating the source code to undesired machine instructions, and a more recent version of gcc doesn't make that mistake.