Package glibc-locales

Wit reference to

And this one which sparked my investigation in glibc-locales package.

If the package is created for usage with ARM - why is it installed with x86_64?

Why is the PKGBUILD absent from the /packages/community repo on gitlab?

The comment trail of the first of above topic indicates - one could simply remove it - but that is generating error messages with locale-gen.

The glibc packages installs it’s own version of locale-gen

 $ cat /usr/bin/locale-gen
#!/bin/sh

set -e

LOCALEGEN=/etc/locale.gen
LOCALES=/usr/share/i18n/locales
if [ -n "$POSIXLY_CORRECT" ]; then
  unset POSIXLY_CORRECT
fi


[ -f $LOCALEGEN -a -s $LOCALEGEN ] || exit 0;

# Remove all old locale dir and locale-archive before generating new
# locale data.
rm -rf /usr/lib/locale/* || true

umask 022

is_entry_ok() {
  if [ -n "$locale" -a -n "$charset" ] ; then
    true
  else
    echo "error: Bad entry '$locale $charset'"
    false
  fi
}

echo "Generating locales..."
while read locale charset; do \
        case $locale in \#*) continue;; "") continue;; esac; \
        is_entry_ok || continue
        echo -n "  `echo $locale | sed 's/\([^.\@]*\).*/\1/'`"; \
        echo -n ".$charset"; \
        echo -n `echo $locale | sed 's/\([^\@]*\)\(\@.*\)*/\2/'`; \
        echo -n '...'; \
        if [ -f $LOCALES/$locale ]; then input=$locale; else \
        input=`echo $locale | sed 's/\([^.]*\)[^@]*\(.*\)/\1\2/'`; fi; \
        localedef -i $input -c -f $charset -A /usr/share/locale/locale.alias $locale; \
        echo ' done'; \
done < $LOCALEGEN
echo "Generation complete."

echo "Copying saved locales..."
cp -a /usr/lib/glibc-locale/* /usr/lib/locale/
echo "Copying complete."

overwrites the original locale-gen script without any backup

post_install() {
  cp -a /usr/lib/glibc-locale/*utf8 /usr/lib/locale/
  cp -a /usr/lib/glibc-locale/locale-gen /usr/bin/locale-gen
}

The unnecessary set of locales is the copied thus ending up taken around 400MB disk space - also on the ISO

 $ cat /usr/share/libalpm/60-glibc-locales.hook 
[Trigger]
Type = File
Operation = Install
Operation = Upgrade
Target = usr/lib/locale/*

[Action]
Description = Restoring locales
When = PostTransaction
Exec = /bin/bash -c 'cp -a /usr/lib/glibc-locale/*utf8 /usr/lib/locale/'

If locale is updated the script is replaced

 $ cat /usr/share/libalpm/locale-gen.hook
[Trigger]
Operation = Install
Operation = Upgrade
Type = Package
Target = glibc

[Action]
Description = Modifying 'locale-gen'
When = PostTransaction
Depends = glibc
Exec = /bin/bash -c 'cp -a /usr/lib/glibc-locale/locale-gen /usr/bin'

When on uninstall the package from an x86_64 system the original locale-gen script cannot be restored - thus generating errors when running locale-gen script

 $ sudo locale-gen
Generating locales...
  da_DK.UTF-8... done
  en_DK.UTF-8... done
  en_US.UTF-8... done
Generation complete.
Copying saved locales...
cp: cannot stat '/usr/lib/glibc-locale/*': No such file or directory

The package also creates confusion about the state of the locale as can be seen from topic number two linked above.

I think this warrants the package removed from community repo and removed from the ISO profile(s) as this would also cut 400MB from the ISO.

On a side note to the above - even the minimal Xfce ISO is at 3G - is that really necessary?

4 Likes

so at first one had to update locale-gen, right? I have been confused by the massive .iso sizes for a long time, but never actually investigated.

 $ pkgfile locale-gen
core/glibc
extra/bash-completion
community/glibc-locales

reinstalling glibc will restore the original locale-gen script

Ah, so we just remove it from the iso-profiles and from the repo are g2g? Great!

Dropped it for manjaro sway. The image is around 30MB smaller. Perhaps the 400MB were before compression?

The figures I mentioned was the roughly calculated based on the size reported by pacman upon sync.

The actual compressed size is next to impossible to calculate.

Since it only took 30MB of the ISO - I still wonder what is generating these enormous ISO size.

1 Like

It is drifting a bit towards the size - I am OK with that - I am responsible - I am really stumped by the ISO size.

uncompressed sizes (lxqt-kwin profile)

The rootfs is 4100MB uncompressed
The mhwd overlay is 900MB
The live over is 100 MB
The desktop overlay is 2400MB

The total of 4 squashfs on the ISO is 2800MB

I am currently trying to understand why the ISO as increased so much.

I remember a few years back lxqt iso was sll-in just below 2000MB

EDIT:

Playing around with the good old lxqt profile - I managed to get a 1.6G ISO.

Of course this could only be done by leaving out the mhwd #! and the mhwdfs.sfs overlay.

So conclusion with relation to the size of the ISO - with convenience comes sacrifice.

EDIT:

the package manjaro-zsh-config puts a hefty load on the ISO.

removing the package from Packages-Root decreases the ISO from 1.9G to 1.6G - compressed

wow. that doesn’t sound reasonable. Any idea what does that? I assumed that that’s just a bunch of scripts…

An innocent looking package - pulls exccessive dependencies.

But I suggest you try yourself.

Simply comment the line in Packages-Root

#manjaro-zsh-config

Besides this I removed Packages-Mhwd and set in profile.conf

mhwd_used=false
mhwd_nonfree=false

will certainly do. removing mhwd stuff I clearly can imagine. for the zsh config so far I didn’t find any evidence of it taking much space on my machine. the whole /usr/share/zsh dir doesn’t take a lot and all its deps seem to install there.

Well, we can recheck ZSH support. mhwd normally gets the drivers it needs on the ISO so offline installations are possible. when the drivers are not present they get downloaded from the internet, which might create however other issues …