[Pkg-ltsp-devel] merging ...

[Vagrant Cascadian]

On Tue, Aug 29, 2006 at 02:10:55PM +0200, Oliver Grawert wrote:
> i just wanted to merge the recent debian changes and stumbled over some
> weirdnesses ....

alright, well most of it is probably my fault :)

> first, please dont do merges into debian from the edgy-ltsp branch, i
> try to keep ubuntu package specifics out of the mainline branch, but
> merge the debian main branch into the ltsp-mainline one ...
> if the debian main branch pulls from edgy-ltsp this distinction is
> somewhat pointless since i get back all stuff from edgy-ltsp into
> mainline through you ...

there was some desire to keep the ubuntu debian/changelog entries in
debian's debian/changelog as well, as it's hard to know what version to
call the debian package without knowing what version the ubuntu-based
one is, and it gives us more of an understanding of how the packages
related to one another.. so i merged the changes for edgy-ltsp largely
for that reason. there were very few differences...

> (i.e. we wont do the tftpd transition this release, so i need to keep
> the dependency there for edgy... we dont want our metapackages to
> explode and dont use aptitude in ubuntu, so i dont use your recommends
> in most places, the edgy-ltsp branch was intended to maintain only ths
> differece from debian, so we dont always clash with the control files)
 
i'm thinking a better way to handle this is to stick our respective
debian directories into distrib/debian and distrib/ubuntu. and then
either symlink or cp -a that to debian when building a package. this way
we can merge changes without having to worry about conflicts, and
manually introduce the changes that actually are common...

> secondly i really love the new update-kernels stuff. but there is one
> major breakage you introduce for all upgrading users by changin the
> default tftp location ... 

when i first brought up the feature, i announced that it would break
compatibility as a drawback, but didn't see any comments about it then.
there is no way i see to maintain the old way and still support multiple
architectures/chroots sanely.

> we cant update the
> existing /etc/ltsp/dhcpd.conf files right away (its a conffile)) 
> i think that needs discussion how to provide a safe upgrade path even
> for ubuntu users who rarely see the commandline before i can merge it :(

i tried to push for doing that split in the very first packages, so we
wouldn't have this upgrade problem, but met resistance from mdz.

we could make a backwards-compatible setting for ltsp-update-kernels,
that does it the old way, and if undefined, does it the new way?

> third i'd like to discuss the USR_LOCAL_SWAP parameter, in ubuntu we
> will solve it with a simple udev rule:
> 
> /opt/ltsp/$ARCH/etc/udev/rules.d/86-ltsp.rules:
> 
> SUBSYSTEM=="block", ENV{ID_FS_TYPE}=="swap", RUN+="/sbin/mkswap %k
> && /sbin/swapon %k"
> 
> which should be waay faster than walking all partitions with sfdisk and
> will be used automatically if a swap partition is avaliable, no need for
> additional lts.conf parameters ;)

doing it from udev is definitely cool, but it does make it more
difficult to set up encrypted swap that way. we could make a script that
gets called by udev and set it up for encrypted swap if configured that
way...

> note that we will start using udev more and more in ubuntu where
> appropriate for hardware related stuff (i.e. the new local device
> support totally relies on udev) ... i know there are some major
> differences between upstream/ubuntu udev and the debian version which i
> dont have time to figure out, it would be nice if someone on the debian
> side could look into that compatibility issues ...

because of the potential differences, and because i think it should be
simple to enable or disable features (even if the default is to
automagically do everything), i'm a little hesitant... but if we can do
more udev stuff while keeping those two things in mind, i'm all for it
:)

by the way, where are these udev rules in your bzr branches? makes it
hard to check for compatibility when i don't know whre to look :)

live well,
  vagrant