Arch Linux

Oops, please IGNORE the first patch, it contains hardcoded /mnt and missing $DESTDIR when looking for mkinitcpio config for obtain the kernel version of installed system. (If not have this, for example it fails when install the system with a "2009.02-FTP" that have kernel 2.6.28-ARCH, and the upstream kernel is 2.6.29-ARCH)

Patch is attached to fix this.

I tested it and worked fine :) Now Arch Linux install more fast :P

I don't want to make any changes to the "old" installer other than showstopper bugfixes.
Next installer will be aif (in nothing big happened), so we should see how aif handle this thing, and if aif could benefit from this patch.
@Dieter: assign this also to you, so you get informed.

This is one of the points of aif's TODO list :) . Doing mkinitcpio twice makes it unnecesarily longer indeed. I reopened and assigned to AIF.

Gerardo, I like your patch, it's a bit hacky but it's a good starting point.
Have a look at http://github.com/Dieterbe/aif/blob/e9c113324dfa3f40206a280f99aa47e4d731debf/src/core/libs/lib-software.sh (installpkg function)
Also check out the run_background , follow_progress functions etc whith allow you to do a cleaner implementation

Btw, instead of putting the "lowlevel" logic in run_mkinitcpio, wouldn't it be much easier+cleaner to just (re)install the kernel on the target system?

hehe :) Yes it's a bit trick

OK, in the next days, i will testing AIF and send patches that from my point of view would be interested.

keep in mind to patch against the experimental branch. it's the bleeding edge :) (and right now it's quite stable btw)

Tobias/Aaron, what do you guys think of this?
I'm thinking about something like this:
- during package installation: do not install kernel26 at all, or install it with --noscriptlet (do any packages depend on kernel26? are there any scriptlets other then mkinitcpio?)
- after configuring the system: install kernel26 normally.

well, if it doesn't affect installation of binary addon modules it would be fine.

Wait, let me rephrase :)

I know _shit_ about the packaging of the kernel/modules, what happens during installation and what I safely can and can't do.

What I do know is that at a certain point during installation all packages get installed to the target the system including the kernel, at which point mkinitcpio is executed.
Later, after the "configure system" step the user *may* have changed his mkinitcpio.conf so we run mkinitcpio again.

Sure we could md5sum mkinitcpio.conf and only run mkinitcpio a 2nd time if the file has changed, but shouldn't it be possible to only run once? (eg after the configure system)
There are several ideas posted on this page.

Please tell me your thoughts, and just tell me what I should do :)

My 2ct: Leave it as it is. It's proofed (pacman does the right job with the kernel). Hacking therein makes the package installation maybe a little faster, but: 1,2 minutes - who cares? Hey, installation is something user will hopefully not do often....

just an other thing, people may want to skip steps in setup, so mkinitcpio should be run at least during package installation.

Tobias, sure they can skip steps, but as long as they exit the installer in a reasonable way (eg don't crash it) we can always put a little check at the end that does a mkinitcpio if it hasn't happened yet.

We might get the "only run once" thing working, but I wouldn't feel very confident in the long term.
It would have been nice, but it's not worth it.
For now, I think the md5sum on mkinitcpio.conf is a good compromise between benefit and code complexity. This should be trivial to patch.

Dieter

are there any other (config) files initcpio depends on? what about /usr/lib/locale/locale-archive? (generated by locale-gen)