On Sunday 2021-07-11 18:31:24 Kern Sibbald wrote: > Hello Sven, > > Yes, I am aware of the FHS policy, which is perfectly fine for 99.9% of > all installed programs, but not ideal for Bacula.
Hello, There is nothing special about Bacula in that regard. Many (if not most) programs require modifications to conform to a specific standard unless the program is following particular rules from the very beginning. Many programs are modified by package maintainers who sometimes have to come up with patches for programs to work as expected because authors sometimes chose to hardcode paths and other options which should be configurable. We are dealing here with two opposite opinions and two different points of view because two types of people are involved here: developers and sysadmins. For a developer the easiest solution is to keep everything under a single directory and to ship a bunch of libraries with the program distribution. This keeps program more predictive and the deployment less complicated. Developers usually don't have to bother with the software deployment and the service maintenance. Every bit of work they manage to spare during the application development by keeping their environment simple will usually get payed by a sysadmin during the deployment and service maintenance. On Unix (and Linux) /opt directory used to be a directory which usually contained optional software distributions provided by a third party companies or vendors. It is rarely used by OpenSource tools or applications. Unless there is no other way (e.g. there is a commercial software distribution with a specific requirements), /opt shouldn't be used by a software distribution. Using /opt is usually a sign of a bad support (e.g. packaging and testing) for a specific system. Note that I am talking in general, not about Bacula specifically. Software that tend to use /opt for its installation usually brings several commonly available libraries locked to a specific version. Providing commonly available libraries already available on the system with the particular software distribution and linking programs with such libraries makes it good thing for the application stability and simplicity of its deployment and ultimately vendor support. However, from a non-developer view there are no visible benefits. >From sysadmin view, it looks like yet another nonstandard software installation with an unusual update procedure which usually turns out to be more of a migration and less of a simple minor version update. Another problem is that it is most likely that libraries shipped with a third-party software will receive their security and bugfix updates far too slow or more commonly, will not receive any updates at all which adds to an overall potential system vulnerability footprint. Also, shipping such common libraries will duplicate the code used on the system. Putting software under /opt could also complicate a diskless setup a bit. Now imagine the horror on the system if most of the services on the system would follow such practice. Such system would be very hard to maintain and the code sharing in memory would be pretty low. Directory structure on Linux systems is the only thing that was relatively well standardized throughout the Linux distributions since the earliest days of Linux and it is interesting to see that what is considered to be a properly packaged software for one person could at the same time be described as "spreading it all over the filesystem" for somebody else. Regards! -- Josip Deanovic _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
