paulwratt
commented
1 year ago I personally support this type of scenario, just know ..
I have been through this exact process with TinyCore Linux, and I can say "its not as simple as it sounds". By that I mean somewhere between 70-80 percent of packages will fit a "programmatic" separation model.
Also note:
- at that time (circa 2017) there was a tendency for packages to drop man pages in favour of info pages , but the majority of packages didn't contain info pages , so it cause no end of consternation.
- often the info pages are just dumped man pages output and don't take advantage of inter-document linking, which is one of the primary reasons for using info pages , on top of the fact they more naturally render to usable HTML format.
- at some point Debian decided that
/usr/share/docs/*should only contain Debian build related docs, so a lot of packages locate theirdocsfolder elsewhere. - also many packages contain development docs instead of end user docs for the main package, instead of in the development package (or in separate *-devel-docs type package).
- there are (now) alot of packages that don't have *.a libraries (for static linking).
As discussed in #60, maybe it would be a good idea to offer the option (default enabled?) to split packages into -devel and -doc by regex', like .h, .a, man, info, etc.? It might also beneficial to have virtually split packages, like gcc-libstdcxx and such, too. But that is a more complex thing, especially if we would want to add support to just build a sub-set of those, and not only do this by post-build flist filtering.