failure to remove package because of build output file

[MartinNowak]

Failed to remove vibe-d ~master: Untracked file found, aborting package removal, file: /home/dawg/.dub/packages/vibe-d-master/libvibe-d.a

dub --help
DUB version 0.9.22-beta.4+23-g617bdf0, built on Jul 16 2014

[MartinNowak]

I first tried to keep track of every file that is added somewhere, but that was pretty messy.
As the journal is currently of very limited use I simply removed it instead.
An install journal is only interesting when we install files out of tree.

[s-ludwig]

The idea was to have a safety net to avoid accidentally deleting user created files. IMO it would have been better to restrict the blind removal to the .dub subfolder. Also, the --force-remove switch doesn't do anything anymore now, so if we stay with this change, a deprecation message would have to be added.

[MartinNowak]

But the build output isn't in .dub, so that wouldn't fix the issue. You're right about the deprecation.

[MartinNowak]

A solution here would be to move binaries for installed packages out of tree, but that might require to change the run path or so.

[s-ludwig]

You are right, I only thought of that after writing the reply...

Since guessing the target binary name is difficult (would have to iterate over all possible os-cpu-compiler combinations), that doesn't sound like a good way to go. Another possibility would be to just add the target binary to the installation protocol during the build (if a protocol exists).

I'll have a closer look later.

[MartinNowak]

There is also copyFiles for which you'd have to update the installed files list.
And there should be hashsums to detect file modifications as well.
Really not sure if it's worth the trouble.

[s-ludwig]

Hm.. or maybe a completely generic approach? Make a directory snapshot before and after each DUB operation (except for the "run" part of "dub run" or "dub test") and update the log with the difference?

[MartinNowak]

Hm.. or maybe a completely generic approach? Make a directory snapshot before and after each DUB operation (except for the "run" part of "dub run" or "dub test") and update the log with the difference?

If you can implement it efficiently. FWIW this is a complex feature with small impact.
A reasonable first measure to discourage manipulation, would be to install files as read-only.
Should also work on windows https://msdn.microsoft.com/en-us/library/windows/desktop/aa365535(v=vs.85).aspx#file_attribute_readonly.