[arch-dev-public] Install files in [core]
Hi, With adding install files to deal with info pages to packages in [core], there are a number of packages with install files that will cause errors if bash is not installed before them (pacman uses /bin/sh from the system it is installing to). An incomplete list: binutils diffutils ed filesystem (also needs coreutils for chmod) findutils gcc-libs (fixed in git) gdbm gettext gmp gpm How do we handle this? Add "sh" to dependencies? Not have post_install for these packages (it is only info page installs...)? I did the later for gcc-libs where it makes sense but other cases are not so clear cut. Allan
On 07/03/10 21:01, Allan McRae wrote:
Hi,
With adding install files to deal with info pages to packages in [core], there are a number of packages with install files that will cause errors if bash is not installed before them (pacman uses /bin/sh from the system it is installing to).
Here goes the complete list of packages suffering from this issue: binutils diffutils ed filesystem (also needs chmod) findutils gcc-libs (fixed in git) gdbm gettext gmp gpm grep grub (also install-info) nano rp-pppoe sed tiacx-firmware (also - cat: command not found) which wireless-regdb
How do we handle this? Add "sh" to dependencies? Not have post_install for these packages (it is only info page installs...)? I did the later for gcc-libs where it makes sense but other cases are not so clear cut.
So any suggestions on how to fix? As an aside, other packages in [core] with non-bash install file dependency issues: autoconf - install-info ca-certificates (several perl warnings: Setting locale failed) heimdal - install-info inetutils - install-info libsasl - cat: command not found mlocate - chown: command not found ndiswrapper - /usr/sbin/ndiswrapper: /usr/bin/perl: bad interpreter udev - warning: can't open /etc/fstab: No such file or directory Allan
Am Montag, 8. März 2010 11:12:08 schrieb Allan McRae:
ca-certificates (several perl warnings: Setting locale failed)
How did you check that? ca-certificates depends on openssl which depends on perl. Or do we have some kind of dependency loop? -- Pierre Schmitz, https://users.archlinux.de/~pierre
On 08/03/10 20:30, Pierre Schmitz wrote:
Am Montag, 8. März 2010 11:12:08 schrieb Allan McRae:
ca-certificates (several perl warnings: Setting locale failed)
How did you check that? ca-certificates depends on openssl which depends on perl. Or do we have some kind of dependency loop?
I used: mkarchroot <dir>/root ca-certificates Here is the error. It is caused by locales not being set: (24/24) installing ca-certificates [#####################] 100% Clearing symlinks in /etc/ssl/certs...done. perl: warning: Setting locale failed. perl: warning: Please check that your locale settings: LANGUAGE = (unset), LC_ALL = (unset), LANG = "en_AU.UTF-8" are supported and installed on your system. perl: warning: Falling back to the standard locale ("C"). Updating certificates in /etc/ssl/certs... 141 added, 0 removed; done. Running hooks in /etc/ca-certificates/update.d....done. I do not know if that could happen on a real install or if it matters. You may just want to /dev/null the output. Allan
On Mon, Mar 8, 2010 at 4:36 AM, Allan McRae <allan@archlinux.org> wrote:
On 08/03/10 20:30, Pierre Schmitz wrote:
Am Montag, 8. März 2010 11:12:08 schrieb Allan McRae:
ca-certificates (several perl warnings: Setting locale failed)
How did you check that? ca-certificates depends on openssl which depends on perl. Or do we have some kind of dependency loop?
I used: mkarchroot <dir>/root ca-certificates
Here is the error. It is caused by locales not being set:
(24/24) installing ca-certificates [#####################] 100% Clearing symlinks in /etc/ssl/certs...done. perl: warning: Setting locale failed. perl: warning: Please check that your locale settings: LANGUAGE = (unset), LC_ALL = (unset), LANG = "en_AU.UTF-8" are supported and installed on your system. perl: warning: Falling back to the standard locale ("C"). Updating certificates in /etc/ssl/certs... 141 added, 0 removed; done. Running hooks in /etc/ca-certificates/update.d....done.
I do not know if that could happen on a real install or if it matters. You may just want to /dev/null the output.
Or just put a LANG=C in front of the command so we don't hide later actual errors that might pop up. -Dan
On Mon, Mar 8, 2010 at 4:12 AM, Allan McRae <allan@archlinux.org> wrote:
On 07/03/10 21:01, Allan McRae wrote:
Hi,
With adding install files to deal with info pages to packages in [core], there are a number of packages with install files that will cause errors if bash is not installed before them (pacman uses /bin/sh from the system it is installing to).
How do we handle this? Add "sh" to dependencies? Not have post_install for these packages (it is only info page installs...)? I did the later for gcc-libs where it makes sense but other cases are not so clear cut.
So any suggestions on how to fix?
dash as /bin/sh? It's only dep (right now) is glibc since we don't have an alternate C library to link against, but it is way more lightweight than bash (no readline dep, etc.) and will probably eliminate some of the headaches we have with regards to deps. -Dan
On 08/03/10 22:54, Dan McGee wrote:
On Mon, Mar 8, 2010 at 4:12 AM, Allan McRae<allan@archlinux.org> wrote:
On 07/03/10 21:01, Allan McRae wrote:
Hi,
With adding install files to deal with info pages to packages in [core], there are a number of packages with install files that will cause errors if bash is not installed before them (pacman uses /bin/sh from the system it is installing to).
How do we handle this? Add "sh" to dependencies? Not have post_install for these packages (it is only info page installs...)? I did the later for gcc-libs where it makes sense but other cases are not so clear cut.
So any suggestions on how to fix?
dash as /bin/sh? It's only dep (right now) is glibc since we don't have an alternate C library to link against, but it is way more lightweight than bash (no readline dep, etc.) and will probably eliminate some of the headaches we have with regards to deps.
That would still require we add "sh" as a dep. We can currently do that with bash as its deps have deliberately have got not no post_install to avoid such errors. I think our choices are: 1) add "sh" as a dep 2) remove post_install where possible I guess in most cases #2 is not possible so the affected packages should have #1 done. Allan
On Mon, Mar 8, 2010 at 1:25 PM, Allan McRae <allan@archlinux.org> wrote:
On 08/03/10 22:54, Dan McGee wrote:
On Mon, Mar 8, 2010 at 4:12 AM, Allan McRae<allan@archlinux.org> wrote:
On 07/03/10 21:01, Allan McRae wrote:
Hi,
With adding install files to deal with info pages to packages in [core], there are a number of packages with install files that will cause errors if bash is not installed before them (pacman uses /bin/sh from the system it is installing to).
How do we handle this? Add "sh" to dependencies? Not have post_install for these packages (it is only info page installs...)? I did the later for gcc-libs where it makes sense but other cases are not so clear cut.
So any suggestions on how to fix?
dash as /bin/sh? It's only dep (right now) is glibc since we don't have an alternate C library to link against, but it is way more lightweight than bash (no readline dep, etc.) and will probably eliminate some of the headaches we have with regards to deps.
That would still require we add "sh" as a dep. We can currently do that with bash as its deps have deliberately have got not no post_install to avoid such errors.
Yes; I thought the reason we didn't add the dep for a lot of these was to prevent dep cycles however. If I'm wrong treat my words here as blowing smoke and I'll shut up. :) -Dan
participants (3)
-
Allan McRae
-
Dan McGee
-
Pierre Schmitz