`dkp-pacman --overwrite='*'` to install over existing files deletes the whole dirtree

[nicholatian]

When installing a package with intent to overwrite existing files, as is often done when moving a manually-installed piece of software to a packaged version, overwriting the old files to put them on pacman’s radar is the way to go.

On Arch Linux this just overwrites whatever files are necessary and everything is fine. On macOS, this deleted and recreated my /etc folder with nothing but the contents of my installed package. This is horribly destructive and needs to be fixed ASAP.

[WinterMute]

• Permanently disabling SIP on macOS is a terrible idea
• Using --overwrite and most especially --overwrite=* isn't something you should be doing even on arch unless you know exactly what's being overwritten and the consequences of that.
• Rebooting into recovery mode, deleting the newly created /etc folder and running ln -s /private/etc /etc should fix the consequences of your actions.

Which package are you trying to force install and why? As far as I know none of the macOS packages we provide touch /etc so this shouldn't be an issue I'd expect our macOS users to encounter.

[nicholatian]

I am using my own packages from the AUR with dkp-pacman because Homebrew is a mess and it doesn’t seem worth it when I’ve already written a bunch of PKGBUILDs.

I know what the consequences of --overwrite are and it does not behave like it does on Arch. The behaviour should be made consistent with that.

[WinterMute]

We can't and won't support building packages from AUR. macOS is not arch and you shouldn't build packages that touch macOS system folders via dkp-makepkg. Sorry but you're on your own if you want to do this.

[endrift]

Not to mention that the behavior discrepancy is certainly a bug that should be filed upstream. This isn't exactly a heavy fork as far as I understand.

[nicholatian]

It really doesn’t matter why, this behaviour still exists and it’s liable to brick people’s computers. and just as well, this is not a bug to file upstream because upstream doesn’t support macOS. is there some other pacman that does this?

[nicholatian]

I am building software that is designed for macOS. I wrote my own PKGBUILDs that specifically accomodate this. Your tool then took a functionality of makepkg, implemented it inconsistently, and nearly bricked my computer. Your tool should apply a patch that causes it not to do that.

[WinterMute]

dkp-pacman is built to accommodate our own software, Your use case is well outside the scope of the support we're prepared to provide for free.

We implemented nothing inconsistently, We built essentially vanilla pacman source for macOS, Your own actions nearly bricked your computer. I refer you to the answer given earlier at https://github.com/devkitPro/pacman/issues/23#issuecomment-714329948

• Permanently disabling SIP on macOS is a terrible idea
• Using --overwrite and most especially --overwrite=* isn't something you should be doing even on arch unless you know exactly what's being overwritten and the consequences of that.
• Rebooting into recovery mode, deleting the newly created /etc folder and running ln -s /private/etc /etc should fix the consequences of your actions.

Which package are you trying to force install and why? As far as I know none of the macOS packages we provide touch /etc so this shouldn't be an issue I'd expect our macOS users to encounter.

It's also worth noting that arch users have encountered problems with symlinks and the advice given is to not use symlinks for any directory managed by pacman. See https://bbs.archlinux.org/viewtopic.php?pid=1783807#p1783807 for example.

[endrift]

It really doesn’t matter why, this behaviour still exists and it’s liable to brick people’s computers. and just as well, this is not a bug to file upstream because upstream doesn’t support macOS. is there some other pacman that does this?

As it turns out, pacman does not support using file paths over symlinks; it will clobber the symlink if you pass --overwrite. So the issue here is not a macOS or downstream bug, it's that your package lists contain files that clobber the symlink, and, despite you saying that you used --overwrite in a way you understand, this makes it clear that you didn't. Further, since you're making your own PKGBUILDs this is your responsibility. If you disagree, file a bug upstream about the symlink behavior (and watch it get closed as WONTFIX). This is 0% the responsibility of a downstream that's being used beyond its intention and to pretend otherwise is misplaced blame.

[nicholatian]

This is 0% the responsibility of a downstream that's being used beyond its intention and to pretend otherwise is misplaced blame.

This behaviour can be encountered with any package. “Intention of use” is a flimsy way to deflect the reality of what’s going on here. Anybody can encounter this behaviour using dkp-pacman, and the very least its maintainers could do is add a warning or something. It’s just irresponsible to leave this closed and buried.

[endrift]

While "anybody" could encounter this behavior on any version of pacman, the truth of the matter is that you did a thing this tool wasn't meant for, using PKGBUILDs you wrote, and you did it while stripping the safety checks in the process. The number of other people who will encounter a situation like this is vanishingly small. Further, it sounds like the packages you're building aren't even respecting how stuff is supposed to work on macOS in the first place (disabling SIP just to install software that most likely doesn't need to go in /usr and /etc in the first place is maybe a sign that you're doing it wrong). You've ignored all of the safety signs already in place and then you're telling us to add more. Why bother if you're just gonna ignore them, and no one else is going to even encounter them? You're just trying to post-rationalize yourself making a mistake into it being someone else's fault. Since you clearly knew what you were doing, it must be someone else's fault, right?

[asiekierka]

If you're using dkp-pacman for packages not in the scope of devkitPro's efforts, wouldn't it be better to just use regular pacman instead?

[nicholatian]

If you're using dkp-pacman for packages not in the scope of devkitPro's efforts, wouldn't it be better to just use regular pacman instead?

devkitPro doesn’t want to support the idiosyncrasies of macOS with their port. It would be even more work for me to do not only what they do, but what they don’t do, and I’m just not that invested in the infrastructure. I work downstream.

[endrift]

Very mature behavior from @nicholatian here

Seriously, why? devkitPro has no responsibility for non-dkP usage of our downstream of an entirely unrelated-to-dkP project. And yet you passive-aggressively blame us when you hit an issue with symlinks that aren't managed by pacman in the first place. This is entirely your problem, and deflecting the blame helps no one. You've refused to even acknowledge any of the points, much less argue against them, and selfishly say it's our fault. You're just flat wrong and it's really unbecoming.