About: slashpackage
The slashpackage convention was introduced by D.J. Bernstein: the /package hierarchy. Round about 20 years later we can state that it is not asserted oneself. IMHO I think there are some good thoughts behind it, but at the end it doesn't fit into existing common structures really. The slashpackage convention can solve some existing issues it addresses. On the other side it has some caveats too.
To me the most important mistake was to develop a scheme which was very aside of common usage. Thus it conflicts heavily with the users interest. It was a to extreme change (request). Sure, the FHS “standard” is a mess. I don't see it even as a “standard”, it is more likely a documentation of commonly existing folders on UNIX'like systems and the try to find a “valid” explanation for each of them. Once more D.J. Bernstein requests to register your (slash)packages with him - may be I'm wrong, but this is a joke (to me). Far away of community practice.
In general there are situations there it makes sense to install a package inside it's own folder against to split all files through the system. As always: The truth is in the middle and you have to find compromises. This tangents package management
and will not be discussed in this article but mentioned below.
Flat versus deep
What does this mean? A flat hierarchy is the number of folders inside one parent folder. So in the / (root) folder the bin , etc , dev , sys and so on are flat. A deep hierarchy means how many folders are in a row (the path). Example: /usr/share/gcc-data/x86_64-pc-linux-gnu/6.4.0/info/ is deep.
Remember the truth is in the middle: to flat is as worse as to deep, isn't it?
Later on I will point out some thoughts about pathes. Let's have a look at two points:
The package contains a lot of binaries and files
There are some heavily overloaded folders with lots of files in it against some folders are containing just one or some files. Examples for overloaded ones are: /etc , /usr/share/ and /usr/bin . One point here is to decide which packages makes sense and which not. First criteria is if a package is really system relevant or not. It doesn't make sense to put coreutils in a separate folder. Against a in itself closed package like eQmail is good candidate as it is not required to boot/run the operating system. Another good candidate is Apache with a lot of virtual servers.
Multiple versions of a package at the same time
This point is really easy to realize as each package will be installed in a folder name package-version, example: eQmail-1.10 . Another version of the same package is installed - inside the same folder - in eQmail-1.09 . The used version is a symlink without the version number (inside the same folder again): eQmail-1.10 –> eqmail . This is flexible and extendable.
/usr/spkgs/eqmail
|-- eqmail -> eQmail-1.10
|-- eQmail-1.09
|-- eQmail-1.10
It is quite easy to handle without a complex package management system. Most of them couldn't even handle different versions of a package. The file system is an efficient package manager here. Another good candidate is php.
The handling of the cases above can be automated easily with simple scripts to handle (even dead) symlinks!
It is quite rarely but sometime two absolute independent packages use the same name for a file and want to install it into the same location. In the worst case it is a shared object file. Installing at least one of them in its own folder solves such an issue.
Pathes
Some people will maybe argue that this could be a caveat, especially if every folder which holds executable will be appended to the PATH variable. And perhaps it will be forgotten to remove it if the package will be deleted. The “deleted” case could be handled easily and automated by a (check) script. We have to question if every executable have to be in the PATH also. This includes to question how often it is required to run the executable from the command line. Afterwards it can be decided to extend the PATH variable or if required binaries could be symlink'd into a folder inside the PATH. Isn't it simple in general?
Blame me: Windoze does have a environment variable APPLICATIONPATH. Would a similar variable be able to simplify PATH handling?
Caveats of the original convention
The initial convention specifies that additional folders should exists inside the package directory. A more or less complete list is listed here. I think this is much to much. It is far away of usable practice, much to complex and over-sized. It extends the required work to handle slashpackage's more than it solves (small) potential issues.
Conclusion
Drawing down the slashpackage convention to some core functionality makes it more useful in some cases. Each case have to be deliberated carefully. Then it could have some benefit. I didn't go very deep into every detail cause I think some issues which still have to be solved are easy to identify. Unfortunately the better concept doesn't win always.