[pacman-dev] base system install and scriptlets

[Aaron Griffin]

On 10/5/07, Dan McGee <dpmcgee at gmail.com> wrote:
> On 10/5/07, Aaron Griffin <aaronmgriffin at gmail.com> wrote:
> > On 10/5/07, Xavier <shiningxc at gmail.com> wrote:
> > > On Thu, Oct 04, 2007 at 10:37:36PM +0200, Xavier wrote:
> > > > Anyway, the scriptlets won't be able to run at all until a base system is installed.. But that's another problem :
> > > > http://www.archlinux.org/pipermail/pacman-dev/2007-August/009148.html
> > >
> > > Hmm, one thing I forgot to ask about this :
> > > does anyone know how the Arch installer handle this?
> > >
> > > It doesn't install all packages twice, does it?
> > > Or maybe sh and its dependencies don't have any scriptlets?
> > > Or if they do, maybe they can be first installed with --noscriptlet, and
> > > then only install everything?
> > > That is :
> > > 1) pacman -S --noscriptlet bash
> > > 2) pacman -S base
> >
> > Last night Dan and I went through this.
> >
> > Firstly, we manually ensured the deps for install scriptlets.
> > Secondly, I made libalpm succeed but complain loudly if /bin/sh is
> > missing for a package that has a scriptlet.
> >
> > There's not much we can do beyond that besides ensuring this stuff
> > manually - perhaps a namcap rule to make sure bash is somehow in the
> > dep chain if an install script is present?
>
> Aaron, a few issues I thought of today:
> 1. Your check looks for /bin/sh in the current environment, not the
> install-root environment. This should be fixable by snprintf-ing the
> root path to /bin/sh and checking if that exists.

Erm. Look at the first added line of the diff:
snprintf(tmpdir, PATH_MAX, "%sbin/sh", root);

I just reused the local variable, hence the poor naming.

> 2. Although bash doesn't have an install script, it does have other
> deps that DO have an install script. Bash depends on the following
> (when all deps are resolved):
> kernel-headers, glibc (install file), ncurses (install file),
> readline(install file)
>
> The best way to resolve these issues would be to have some sort of
> staticly compiled sh...but I don't know if that is practical. Anyone
> have some ideas for this situation? It sounds like we can't use the
> --root parameter correctly to install a base system without either
> installing twice as was stated above.

It sounds complex... but it works fine right now - try it and then
chroot to the system, everything is in working order.