Anonymous
For example, if I want to install firefox and libreoffice language package for German language, I ask apt to install
firefox-esr-l10n-de
libreoffice-l10n-de
Yes, toward understanding, please do research this example.
List the files intalled by each of these packages:
dpkg -L firefox-esr
dpkg -L firefox-esr-l10n-de
and notice that ZERO instances of overlap (collision, conflict) exists between their installed files.
libreoffice languagepack “packages” are each fairly large, so it’s unsurprising that files for each locale are split across manymany individual packages.
If you compare libreoffice-core vs libreoffice-l10n-de, you will again notice: zero overlap
For spacefm, the cumulative localization files were not regarded as being large enough to each merit its own, separate, package. The debian packager (mati75) did split the collective set of localization files into one separate (separate from the spacefm executable file) package… but for a different reason (i.e. without regard to size). Debian compiles the “spacefm” package, multiple times (for i386, for x86_64, etc.) and adds these architecture-specific packages into the download repository. For the “spacefm-common” package which provides the localizations, only one architecture-independent copy is needed in the repository.
-=-
Repositories, plural (testing, stable, xxyy-backports, oldstable, etc)
multiplied by (?) eight supported CPU architectures
multiplied by approx 30-thousand packagenames.
-=-
Availability of the spacefm-common package precludes the need to redundantly pack those files into
40 “flavored” .deb files
(testing, stable, xxyy-backports, oldstable, etc) x (eight supported CPU architectures)
spacefm “depends on” spacefm-common.
dpkg will refuse to install the former without the latter.
Attempted removal of spacefm-common will forcibly remove spacefm.
Debian packages, and provides for download on antiX systems, the spacefm-common.
Please “dpkg -L spacefm-common” and note the myriad files it provides (installs, “owns”)
An in-house maintained spacefm-common package, distributed via antiX repository
could simply declare a higher package version number and would be recognized
as “the same owning package” ~~ all the localization files could be injected, en masse, via “regular apt upgrade”.
dpkg “knows” each and every one of these installed files, and guards them from being overwritten by any package other than the one which installed ’em.
“Hi. I made a superior ES translation file for spacefm.”
^—— If spacefm-common LACKS a localization file for that particular locale, it could be bundled into a new (call it “spacefm-common-extra” for example) package and installed without conflict ~~ identical scenario to the separate firefox-esr “translation packs”. If, however, an installed by spacefm-common es_ES file already exists… any other package which attempts to replace it will be stonewalled.
http://packages.debian.org/buster/all/spacefm-common/filelist
/usr/share/locale/es/LC_MESSAGES/spacefm.mo
“Hi. Thats’s great! To have your file added into the distribution, you will (must) now…”
http://packages.debian.org/buster/spacefm-common
^—v
http://tracker.debian.org/pkg/spacefm
…contact the maintainer of the spacefm-common package