Installing a subset of available i18n/l14n package files

RalphCorderoy · 2018-02-01 13:21:20

The foreign language translations, etc., for programs is quite large, and only going to increase with time, hopefully.
Has any thought been given to having a package define what files are for what locale so only some are then installed?

I think Fedora 24 gained https://fedoraproject.org/wiki/Changes/ … bpackaging that tackled the problem.

Debian (and Ubuntu) has localepurge(1) but it's an acknowledged hack that deletes files without package management's knowledge so later integrity checks will have lots of complaints. https://anonscm.debian.org/cgit/collab- … ocalepurge

arojas · 2018-02-01 13:45:05

RalphCorderoy wrote:

I think Fedora 24 gained https://fedoraproject.org/wiki/Changes/ … bpackaging that tackled the problem.

How does this tackle the problem? It only concerns glibc AFAICS, applications will still install all their translations

Trilby · 2018-02-01 13:50:28

https://wiki.archlinux.org/index.php/Pa … _to_system
https://bbs.archlinux.org/viewtopic.php?id=226188
https://bbs.archlinux.org/viewtopic.php … 4#p1720894
https://bbs.archlinux.org/viewtopic.php … 6#p1637506
...

RalphCorderoy · 2018-02-01 17:32:00

Hi arojas,

> It only concerns glibc AFAICS, applications will still install all their translations

glibc was the motivator, but the solution works for any package foo: foo-langpack-fr contains the French i18n, langpacks-fr can also pull that in. It's up to each package to use langpacks, libreoffice is one IIRC. https://fedoraproject.org/wiki/Packaging:Langpacks

eschwartz · 2018-02-01 17:46:05

Arch Linux does not create 400 split packages just to save you a few megabytes of disk space.

Trilby · 2018-02-01 19:04:32

Especially when (as indicated in the links in my previous post) all these language files are pretty well marked within the packages already: just don't let pacman extract the ones you don't want.

RalphCorderoy · 2018-02-03 14:54:57

Hi Trilby,

> https://wiki.archlinux.org/index.php/Pa … _to_system

Thanks. pacman.conf(5) says `Shell-style glob patterns are allowed' and fnmatch(3) is used.
FNM_PATHNAME isn't passed so `*', etc., match `/', which might be surprising given that's not "Shell-style".
Also, it would be nice if FNM_EXTMATCH were passed as globs can be a bit restrictive sometimes.

I think `pacman -Qk' will be happy files are missing because of NoExtract, but am I right that it uses
the current NoExtracts rather than those in place during the package install?

Having created NoExtracts, does re-installing a package have pacman remove those now unwanted?

Trilby · 2018-02-03 14:58:27

RalphCorderoy wrote:

Having created NoExtracts, does re-installing a package have pacman remove those now unwanted?

It would probably take less time for you to try it and know for sure than it would to post here and wait for an answer.

But NoExtract isn't even relevant to this question. What does pacman do in an update when a file that used to belong to an old version of a package no longer belongs to that package? Does it just leave that old file around abandonned? (hint: no).

RalphCorderoy · 2018-02-03 15:27:34

By trying it, I only know the practical answer, not the intended one. :-)

`pacman -Qk' does use the current NoExtract so if they change it can report files are missing that it previously left out.
Re-installing a package removed files now matched by NoExtract, but matching directories are either left behind, or they are still created.
A means of applying current NoExtract through fnmatch(3) to what's obtainable by `pacman -Qql' would be nice to save lots of re-installing. (Metered Internet here.)

Trilby · 2018-02-03 17:15:33

RalphCorderoy wrote:

Re-installing a package removed files now matched by NoExtract

That's the effect, but not really the process. As I hinted (I thought not so subtly) at above, pacman doesn't specifically remove files matched by NoExtract; it removes all files that belong to the old version of the package as it installs all files belonging to the new package.

RalphCorderoy wrote:

but matching directories are either left behind, or they are still created.

And is this a problem?

RalphCorderoy wrote:

A means of applying current NoExtract through fnmatch(3) to what's obtainable by `pacman -Qql' would be nice to save lots of re-installing. (Metered Internet here.)

This doesn't make sense. You want a list of packages to reinstall in order to trigger the cleaning of those files you don't want? That is about the most confusing and indirect way to achieve the end goal. Just delete the files: you already created a list of them for your NoExtract. But if you really want to know what packages own them, `pacman -Qo` will tell you that.

I also don't know how metered internet is relevant here. NoExtract prevents the files from being extracted, it doesn't change what is downloaded. Even if you mean for reinstalling, you should have at least the current version of each package still in your cache - so nothing is downloaded when you reinstall a currently installed package.

Last edited by Trilby (2018-02-03 17:24:22)

Arch Linux

#1 2018-02-01 13:21:20

Installing a subset of available i18n/l14n package files

#2 2018-02-01 13:45:05

Re: Installing a subset of available i18n/l14n package files

#3 2018-02-01 13:50:28

Re: Installing a subset of available i18n/l14n package files

#4 2018-02-01 17:32:00

Re: Installing a subset of available i18n/l14n package files

#5 2018-02-01 17:46:05

Re: Installing a subset of available i18n/l14n package files

#6 2018-02-01 19:04:32

Re: Installing a subset of available i18n/l14n package files

#7 2018-02-03 14:54:57

Re: Installing a subset of available i18n/l14n package files

#8 2018-02-03 14:58:27

Re: Installing a subset of available i18n/l14n package files

#9 2018-02-03 15:27:34

Re: Installing a subset of available i18n/l14n package files

#10 2018-02-03 17:15:33

Re: Installing a subset of available i18n/l14n package files

Board footer