RE : [Cooker] urpmi : bad install ordering for Scratch installation

2002-12-02 Thread BERNARD Sebastien
Title: RE : [Cooker] urpmi : bad install ordering for Scratch installation







-Message d'origine-
De : François Pons [mailto:[EMAIL PROTECTED]] 
Envoyé : lundi 2 décembre 2002 16:09
À : [EMAIL PROTECTED]
Objet : Re: [Cooker] urpmi : bad install ordering for Scratch installation



Le lun 02/12/2002 à 13:03, BERNARD Sebastien a écrit :
> I'm trying to install a UML install using urpmi - no really différent 
> than a chrooted installation. I wrote a small perl script which is 
> doing a chrooted install of all packages.
> 
> Doing something like :
> Rpm --root  --initdb
> 
> Then basicaly
> Urpmi --root  
> 
> My problem is that urpmi got the dependancy list wrong.
> The postinstall scripts are trying to use packages which are not 
> installed yet. These are :
> sh-utils, diffutils, time, grep, gnupg, findutils, binutils, make,
> SysVInit, libsasl (libtermcap.so.2 not found ).
> Console-tools (cannot find add-help in rpm-helper installed after)
> Vim-minimal, gcc, gcc-cpp (/usr/bin/perl bad interpreter, in
> update-alternatives, perl is not yes installed).


It is mandatory to include basesystem in the list of package, check you have done that (normaly requires should be good but... base package are always installed and could lead to missing dependencies ?)

[SBE] Indeed, it is in the filelist. Do you mean that I have to install a list of basic packages first then all the others ?

> Maybe the dependency list is not right for certain packages.


What gives urpmq --list | grep  to check repository is right.
[SBE] All packages are there.


> For example: perl-URPM does not need perl ???


It requires perl-base and not perl, that's normal (maybe a bad example).
[SBE] My mistake. The point is if I give the list of the packages on one single line, the order of package
[SBE] installation is wrong in the way I described in my previous mail.
[SBE] I was expecting that given a full list of packages, the installation should have gone smooth.
[SBE] In fact it hasn't. I don't know if the culprit is the urpmi, the rpm or the packages dependencies.
[SBE] My workaround is to do 2 urpmi : one for the packages that must absolutely be installed before
[SBE] And another one to install the rest.
[SBE] In the first one, I have :
[SBE] filesystem libtermcap2 perl fileutils glibc rpm-helper SysVinit initscripts sh-utils
[SBE] But basicaly, the package openssh-server should not be installed before the package rpm-helper if its
[SBE] postinstall script try to invoke add-service for example.





Re: [Cooker] urpmi : bad install ordering for Scratch installation

2002-12-02 Thread François Pons
Le lun 02/12/2002 à 13:03, BERNARD Sebastien a écrit :
> I'm trying to install a UML install using urpmi - no really différent
> than a chrooted installation.
> I wrote a small perl script which is doing a chrooted install of all
> packages.
> 
> Doing something like :
> Rpm --root  --initdb
> 
> Then basicaly
> Urpmi --root  
> 
> My problem is that urpmi got the dependancy list wrong.
> The postinstall scripts are trying to use packages which are not
> installed yet.
> These are :
> sh-utils, diffutils, time, grep, gnupg, findutils, binutils, make,
> SysVInit, libsasl (libtermcap.so.2 not found ).
> Console-tools (cannot find add-help in rpm-helper installed after)
> Vim-minimal, gcc, gcc-cpp (/usr/bin/perl bad interpreter, in
> update-alternatives, perl is not yes installed).

It is mandatory to include basesystem in the list of package, check you
have done that (normaly requires should be good but... base package are
always installed and could lead to missing dependencies ?)

> Maybe the dependency list is not right for certain packages.

What gives urpmq --list | grep  to check repository is
right.

> For example: perl-URPM does not need perl ???

It requires perl-base and not perl, that's normal (maybe a bad example).

> The last problem I got is that the kernel (which I do not need but I
> have to put it there to make the dependancy happy) is trying to
> execute lilo which fails miserably (of course). How can I disable this
> post-install script ?

install kernel manually using --noscripts or create a false lilo package
with a /sbin/lilo being /bin/true ?

François.