[PATCH]: Fixes and Features, misc things
- Subject: [PATCH]: Fixes and Features, misc things
- From: daniel at debian.org (Daniel Baumann)
- Date: Mon, 09 Jun 2008 10:01:02 +0200
- Message-id: <484CE33E.firstname.lastname@example.org>
- In-reply-to: <email@example.com>
- References: <firstname.lastname@example.org>
> 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
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