[PATCH]: Fixes and Features, misc things

[daniel at debian.org (Daniel Baumann)]

Thanatermesis wrote:
> This Patch contains misc fixes, features, and similar things, read the
> .diff file searching the word "Comment" where ill try to explain a bit
> what is every thing

ok.. i took the time to look at each thing you proposed:

1. adding -hide-rr-moved to GENISOIMAGE_OPTIONS

official debian-installer cds are not doing this, so i think we
shouldn't do this either.

2. adding -graft-points to GENISOIMAGE_OPTIONS

how do you make use of that? injection of arbitrary content into the iso
is already covered by config/binary_local-includes

3. adding grub-gfxboot handling

ack with otavio, shoudn't be added unless gfxboot makes it into debian.

4. adding -proccessors to MKSQUASHFS_OPTIONS

i never had any troubles with building in parallel, and i do a lot of
builds, but only on i386 and amd64. where do you experience problems, on
a different arch?

5. adding -no-fragments to MKSQUASHFS_OPTIONS

it could probably makes sense to use -no-fragements, however, do you
have any numbers about the impact on increasing filesize?

6. adding -noappend to MKSQUASHFS_OPTIONS

this will not have any effect, because the squashfs is always
regenerated from scratch when you build it (unless you cache it, but
then it doesn't matter anyway too).

7. executing lh_chroot_local-hooks before lh_chroot_hooks in lh_chroot

generally, you are right. however, specifically the problem here with
this is, that the default hooks which can be enabled, such as 'stripped'
and 'minimal', would potentially make any local hook non-working. that
is why local hooks need to processed first and not the other way round.

8. addition of lh_chroot_hooks

this does the same as the already existing lh_binary_hooks, no?

9. addition of lh_chroot_edit

this does the same as the already existing LH_INTERACTIVE=shell
mechanism, no?

10. changes in lh_chroot_sources

moving the local repositories to the top for the chroot indices makes
sense as they should be prefered, however, i'm unsure as the common way
to write it is to write official repositories first, and custom ones
later. Otavio, do you have any opinion about that?

making the indices caching conditional is not in all cases relevant,
since some of them are always existing (like the gpg files, the binary
package indices), but some are not (like the source indices), so only
making the latter conditional which I'm just applying in git now, thanks.

-- 
Address:        Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist
Email:          daniel.baumann at panthera-systems.net
Internet:       http://people.panthera-systems.net/~daniel-baumann/