Refactor installation instructions and update paths

[duantihua]

1. In a Linux environment, libraries are installed by default to /usr/local/lib64
2. Fix the inconsistency between /usr/local/include in the documentation and /usr/include in the scripts
3. Fixed the copy error in the include library

[dlang-bot]

Thanks for your pull request and interest in making D better, @duantihua! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.
Please verify that your PR follows this checklist:

• My PR is fully covered with tests (you can see the coverage diff by visiting the details link of the codecov check)
• My PR is as minimal as possible (smaller, focused PRs are easier to review than big ones)
• I have provided a detailed rationale explaining my changes
• New or modified functions have Ddoc comments (with Params: and Returns:)

Please see CONTRIBUTING.md for more information.

---

If you have addressed all reviews or aren't sure how to proceed, don't hesitate to ping us with a simple comment.

Bugzilla references

Your PR doesn't reference any Bugzilla issue.

If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog.

[schveiguy]

I have no /usr/local/lib64 on my ubuntu 22.04 system. You sure this is right?

[jmdavis]

Part of the problem is that which set of lib folders a distro has is distro-specific. AFAIK, there is no standard that they all follow. They could have lib and lib64, or they could have lib, lib32, and lib64, or they could potentially have just lib. If they're there, lib32 is going to have 32-bit libraries, and lib64 is going to have 64-bit binaries, but lib could have either depending on the distro - though at this point, the odds are much more likely that lib will contain 64-bit binaries, since 32-bit is dying off.

On my Debian 12 system, /lib, /lib32, and /lib64 are all present, and they're links to /usr/lib, /usr/lib32, and /usr/lib64 respectively. However, /usr/lib64 seems to only be there because of a single symlink to a library in /usr/lib. So, debian seems to really be set up to use /usr/lib and /usr/lib32 and not /usr/lib64.

On my Arch system, /lib and /lib64 are present, and they're both symlinks to /usr/lib. There's then /usr/lib, /usr/lib32, and /usr/lib64, and /usr/lib64 is just a symlink to /usr/lib. So, Arch also seems to be set up with the idea that lib is for 64-bit libraries and lib64 is probably just for compatibility.

So, based on both of those distros, it would seem that the correct thing to do would be to treat /lib and /usr/lib as being for 64-bit libraries and not use /lib64 or /usr/lib64 at all. But other distros may do things differently.

Either way, if we're dealing with /usr/local, things get even murkier, because Linux distros don't normally use /usr/local for anything. Third parties may install stuff there when the files aren't being installed by a package, but because the distros don't have any files in there, they arguably don't define what should be done there either. So, it's debatable as to what the "standard" way to lay the files out is with regards to /usr/local/lib or /usr/local/lib64, but it seems like the way that things are going in general is to move towards treating lib as 64-bit and to not use lib64, because 32-bit is dying out. So, I'm not sure that making stuff that currently uses /usr/local/lib use /usr/local/lib64 instead makes much sense.

[0xEAB]

0xEAB wrote on Discord:
Feel like this stuff should get put into /opt with symlinks in /usr/local/bin for executables.

I'm not a fan of littering system directories with third-party packages (unless packaging is done up to distro standards).

[adamdruppe]

opend instructs users to keep the downloaded package together and just put a forwarder in path. Everything else then works relative to the thisExePath. Advantages include:

• easier uninstall. just nuke the one directory and (optionally) delete the forwarder, not hunting across different paths.
• easier updates, since you just replace the one directory, without having to uninstall the old to avoid leaving files behind that break (anyone remember when std.datetime got broken up into packages and users flooded the forum with problems because the old datetime.d and the new datetime folder lived side by side?)
• easier parallel versions, you can have as many directories as you want without overwriting each other (the forwarder can even specify version in its name, or you use a direct path when you want a specific version)
• configuration is separated per-version
• does not require root access, users can do it entirely contained in their personal accounts by putting it in ~ instead of /opt.

Disadvantages include:

• configurations living with the package means user customizations may have to be redone after updates. (somewhat common to have the package one just include, if exists, some user config extension file so they can be separate). note that updates may also change config meaning, requiring user to fix up their custom things anyway, but this virtually never happens with dmd
• you might want several forwarder programs / symlinks for dmd, dub, ddemangle, dustmite, etc. opend consolidates all under one thing but you don't so it might take more. Alternatively, you could add /opt/dmd/bin to PATH but then you lose some of the parallel version advantages.
• some pedantic types might be like "man 7 hier" but you can reply to them "/opt should contain add-on packages that contain static files so booyah".

I have never "installed" a D compiler in all the time i used it. The advantages are compelling to me. (Actually fun fact, that's why I used Digital Mars C++ back in the day too: I could install it without admin access on the computer. I burned it to a CD-ROM and used it right off that disc, a truly portable install lol.)

[duantihua]

I have no /usr/local/lib64 on my ubuntu 22.04 system. You sure this is right?

There is indeed no such directory on Ubuntu 22, I encountered it during installation on CentOS. I have looked up some information, considering the wide distribution of Linux,/usr/local/lib seems more suitable.And submitted a restoration for repair.

@jmdavis Thank you for your explanation regarding the role and considerations of lib on different Linux systems.