(so... at risk of cross-posting insanity, i have posted this to the ltsp-developer list as it's purely LTSP related changes, and only tangentially related to CDDs- perhaps futher discussion of this specific thread should go there: http://lists.sourceforge.net/lists/listinfo/ltsp-developer) > > http://llama.freegeek.org/~vagrant/baz-archive/vagrant@freegeek.org--2005/ > > > > you should have considerably better luck, i hope. :) > Much better. I've started reviewing your patches; thanks for separating > them out. > patch-1 drop direct modification of /etc/exports in postinst/postrm to comply with debian policy > > You seem to imply that modifying /etc/exports is a policy violation. > Did you assume it was a conffile? (it isn't) upon looking into it, in debian sarge, nfs-kernel-server has /etc/exports listed as a conffile. but my impression is that editing of other packages configuration files is also not allowed, though i couldn't really find this in debian-policy explicitly. in 3.6.1.1, section 10.7.4, it seems like you need to use a provided tool to configure another package's configuration files(such as update-inetd). in general, it doesn't seem like good practice for one package to modify the configuration of another without administrator intervention... even though it's really tempting to do. maybe i'm wrong. > patch-2 support for tmpfs+bind mount alternative to unionfs > patch-3 Improved descriptions > patch-4 Corrected log message for patch-3 > patch-5 allow ssh as alternative to openssh-server and openssh-client for sarge compatibility > patch-8 Copyright file changes > patch-9 Explicit python dependency > patch-10 support initrd-netboot-tools as alternative to initramfs-tools > patch-12 TODO.Debian > patch-13 sdm support > > Merged into mainline great! > patch-6 Use atftpd in preference to tftpd-hpa > > Why is atftpd preferable? i believe it is debconf pre-seedable, which is useful to CDDs. both tftpd-hpa and atftpd work with PXE, i believe. > patch-7 only set "LTSPROOT" and "clients" variables if not already set, pass these variables to ltsp-update-* from ltsp-build-client > > The hardcoded values do need to go away, but this isn't how I intended > for it to work. ltsp-update-kernels and ltsp-update-sshkeys always > need to scan all client trees on the system, i.e. all of /opt/ltsp. well, i needed them to work with the root dir configureable, and that was the smallest change i could get for that to work. if you go with the defaults for ltsp-build-client (/opt/ltsp/ARCH), i believe the behavior is unchanged(ltsp-update-kernels gets passed /opt/ltsp, although ltsp-update-sshkeys will inherrit the appropriate architecture /opt/ltsp/ARCH instead of hard-coded /opt/ltsp/i386). > patch-11 /etc/default/ltsp-client-setup > > I merged this, then made changes to it: > > - Use debhelper to install the /etc/default file much better to use debhelper, yes :) > - Use an FHS-compliant directory (/var/run/ltsp) using /var/run/ltsp won't work unless you move ltsp-client-setup to later in the boot process, as /var/run gets cleaned shortly afterward (S35mountall.sh, on debian sarge). > patch-14 apt-get dist-upgrade in ltsp-build-client > > I don't understand why you did this; please explain probably shouldn't have made the commit at that point- later in the patches an extra mirror is added, which could possibly be security updates or other package updates. it would probably be good to allow several additional mirrors. lessdisks currently allows 5, though clever ways to allow an arbitrary number would be even better. > patch-15 Parameterization of ltsp-build-client > > Please don't change the defaults at the same time that you make > other changes; it makes it more difficult for me to merge with hindsight, i see that i should have made smaller changes with that patch. i should have simply started with the test -z "$FOO" && FOO=bar, and made add-on defaults for sarge and etch, rather than putting the breezy defaults into a case statement. i was reverse-patching code that i had worked on for several days, so it was a little tricky to get all the patches the way i would if i had been properly using baz during development. so, where do we go from here, since... > patch-16 > patch-17 > patch-18 > > Conflicted, presumably require patch-15 many of the patches are dependent on patch-15. though there are a few later ones that probably don't require it. of all the things needed in my opinion, dropping hard-coded values from ltsp-build-client configuration is the most important thing, and patch-16 introduces commandline options, which would be really nice. i'm already up to patch 40... though everything after 25 is considerably smaller patches, with hopefully less cruft. trying to merge your changes back in, i get plenty of conflicts in debian/changelog... i suppose i should probably maintain a separate branch for parts i don't expect to be shared. though the biggest problem is that i've got two identical ids or something, and 'baz status' chokes on this... ugh. seems like petter also encoutered this problem, with more details posted :) live well, vagrant
Attachment:
signature.asc
Description: Digital signature