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: [EMAIL PROTECTED] Internet: http://people.panthera-systems.net/~daniel-baumann/ _______________________________________________ debian-live-devel mailing list debian-live-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/debian-live-devel