This is actually explained in the last question here:
/usr/share/doc/base-files/FAQ
Isn't that quite unfortunate?
It leaves out any legacy installations (and many people never re-
install Debian, but just continuously upgrade it).
I mean I can fully understand if it's to fragile to automatically
update base-files (not just creating new dirs, but e.g. also changed
directories), but:
- Wouldn't it be possible to have a small tool that is manually run and
which e.g. compare the current situation with what a pristine
installation would get and that spits out some commands that would
adapt this... or per default be like --dry-run and only with some
extra param do everything?
- Or at least *if* something changes - which is anyway quite rate - it
should IMO into NEWS.Debian and the release notes, so that people
that upgrade can catch up.
I think you might be overestimating the importance of this.
An empty directory does not have any "functionality" by itself.
It's just a placeholder, and it's there mainly to satisfy FHS
compliance tests, nothing more. In Debian, all the stuff is
in /usr/bin et al. We don't really need any of those directories.
The end user is not actually missing anything important by having
more or less empty directories in /usr/local. The typical ./configure
script used by autoconf and friends which would install things in
/usr/local/libexec will probably do so regardless of the directory
already existing or not.
So, on the side of NEWS.Debian, no, I don't think this is relevant at all.
We should not bother the end user for non-important things.
Regarding your idea of writing a script which "updates" all those
minor things: Feel free to do so, but I don't think it belongs
to base-files. In fact, there are a lot of things which differ between
an upgraded system and a newly installed system, and the differences
due to more or less empty directories in /usr/local are probably
the least important of all of them.
BTW: Having said that, I should add that I share part of your feelings.
I used to maintain several computer labs, and sometimes I used to do
upgrades from oldstable to stable using ansible. After upgrading the
packages, I often had additional recipes to achieve exactly what you
mention: that an upgraded system is as close as possible to a newly
installed system. If you have time and motivation to work on
such things, here is an idea: investigate what kind of tool we could
use to replace deborphan, since it has just been removed from trixie and sid.
Thanks.
