>Duncan Roe wrote: >> >> Distributors typically use the default config to make a package. That would mean >> libmnl would go out without any documentation, hardly an encouragement to use >> it. It is true that distros commonly go with upstream default. When the upstream default is on "auto" however, it becomes a distro default, which, due to a blank recipe, quickly becomes "no-documentation". (Because of this, openSUSE was embarassingly not building libmnl-doc.) As to whether that is an impediment to creating libmnl-exercising software, I cannot say. Having worked extensively with wxWidgets (also doxygenated) in the past however, I found that when the API is large, needs frequent lookup, documentation has many pages, and online retrieval latency becomes a factor, I prefer a local copy as a quality-of-live improvement. On Monday 2024-10-14 10:09, Pablo Neira Ayuso wrote: > >We do not have control over the specific items that distributors >choose to include in their packages. >[...] the final decisions regarding package contents >rest solely with the distributors. Well, not quite. Removals are a powerful action that is seldomly undone at the distro levels, so it can be regarded as the final say (well, in "95% of cases"). Think of: * deprecated C APIs (distros would rather patch consumer programs to work with the new ones) * GNOME desktop, which is infamous for removing stuff due to confusion ([1]) [1] https://medium.com/@fulalas/gnome-linux-a-complete-disaster-feb27b13a5c2 Hiding stuff behind a configure knob is not a removal though, so it is not too big a deal. >Moreover, documentation is specifically designed for developers who >are engaged in the technical aspects. Most users of this software are >building it because it is a dependency for their software. ^^^^^^^^^^^^^^ The way it's phrased makes those users users of the libmnl API (i.e. developers), and documentation is warranted. (The following statement would be more accurate: >Most users of this software are >building it because it is a dependency for someone else's software >they want to utilize. Anyway, looking at what distros _are_ doing is an indicator what "users" (intermediate consumers, or users at the end of the build chain) desire and what is worth doing upstream somehow. * ICU manages documentation separately; in a sense you could see this as --enable-doc=no. The ICU APIs are however apparently complicated enough that documentation is desirable to have available, and so you do find libicu-doc/icu-doc in distros. * the closer a software is to the bootstrap core, and the more outrageous the build requirements for some (sub)component(s) are, there more likely it is for those (sub)component(s) to be built in a two-phase build or be completely omitted due to complexity. * texlive * pandoc * ant/maven * rust/ghc/go docbook/asciidoc seems right on the edge (because of its potential to depend on a latex backend), but doxygen seems easy.
