- fix FS#46694

- https://www.archlinux.org/todo/use-gpg-signatures-and-https-sources/
- support remote patch

- cleanup vars

- give more realistic examples in /etc/crypttab (FS#34452)

- sync group with gshadow (FS#40953)
- add input group

- add systemd-* users to stock shadow file (FS#40800)
- run pwdconv/grpconv if we touch passwd/group, respecitively (FS#40800)

- preemptively add systemd-network user/group

This removes redundant entires due to the newly introduced symlinks
and also reorders the entries to follow the system-wide PATH set by
systemd.

remove post_install script so filesystem cam be added as a glibc dep - all functionality moved elsewhere, remove deps in base only needed for post_update

move /lib and /lib64 symlinks from glibc, add /usr/lib64 symlink, requires changing from arch=any package

/media is now shipped with udisks1, so the rest of us can drop it

emtpy /tmp from fstab as it is done by systemd automatically (can still be overridden with fstab)

Agan from Jason St. John

From Jason St. John

(the previous commit to initscripts should have read "kill archlinux and locale.sh")

    locale.sh: add support for user-specific locale.conf
    
    We use the first configuration file we find out of:
    
     * $XDG_CONFIG_HOME/locale.conf
     * /etc/locale.conf
     * /etc/rc.conf
    
    All subsequent config files are ignored. E.g., an emtpy /etc/locale.conf
    means that LOCALE from rc.conf is ignored.
    
    Note that currently $XDG_CONFIG_HOME is unlikely to be set when
    locale.sh is sourced, so it will not have any effect. In the future this
    might change, so we kept it in.
    
    This will easily allow users to set one locale to be used for
    daemons/boot and a separate one to be used for users consoles etc.
    
    This eliminates the need for DAEMON_LOCALE, so remove that
    functionality. A post-install note will be added.
    
    The constraints that led to this suggestion:
    
    1) The default locale should work even if locale-gen has not been run,
       i.e., it should be "C".
    2) It is common to want the system locale to be "English", which a
       priori "C" satisfies. However, "C" is not UTF-8, which causes issues
       when the user locale is in UTF-8 (as it is the system locale that
       configures the console mode).
    3) Users might (and often do) want a different locale than what is used
       system-wide. Moreover, different users might want different locales.