@Darkless012 Can you please take a look at easybuilders/easybuild-easyblocks#1989 that is covering similar ground with a different approach, I get the impression we will need to synchronise our approach among that and your upcoming tarball PR

Having the option to merge folders is a nice addition. However, I'd like to point out that it won't solve the issue with tarball easyblock as it is very unlikely that two source code trees can be merged in the same folder. I proposed to add an option to unpack the tarballs in specific subdirectories in easybuilders/easybuild-easyblocks#1989.
I think that both options are compatible and should be added to tarball easyblock as long as none of them is made default. @Darkless012 If there is anything I can do to help synchronize those changes to tarball let me know.

Thank you for noticing, agreed :)
Lets discuss this in mentioned Tarball Easyblock PR.

However, I'd like to point out that it won't solve the issue with tarball easyblock as it is very unlikely that two source code trees can be merged in the same folder.

Why is that an issue? It's say it's quite uncommon that two different software packages would include the same files, and hence problems would ensue when copying the files into an already existing directory?

This is exactly what traditional package managers do by throwing everything in /usr for example...

Am I overlooking something? (I haven't looked at easybuilders/easybuild-easyblocks#1989 in detail yet)

@boegel one thing is to put all executables in a common bin folder or all libs in a common lib as it can be assumed that they will have different names. But merging whole tarballs is a different matter in my opinion as it is unpredictable if files might share the same name and relative path. I see it more closely related to what is done by traditional package managers in /usr/share.