Heimdal Futures

Andrew Tridgell tridge at osdl.org
Wed Jul 6 00:31:22 GMT 2005


 > Now, some may say this is because of a bad design decision, but the
 > alternatives were indeed far, far worse.  Even so, my first priority has
 > to be to reduce the amount of effort this part of my large job takes,
 > and this is why I want, as an end result, to have a 'place heimdal 0.8
 > release tarball here' solution.

yes, I'd like to be able to use a heimdal release tarball too, but I
don't see why having those extra 1400 files in our tree helps with
that at all.

To make this debate a bit more concrete, here is what I propose to


With the way we have the code now, you can unpack either
heimdal-mini.tgz or the heimdal-lorikeet trees into samba4/source/ and
build fine. The 'mini' heimdal is a strict subset of the files in the
full heimdal.

The trick will be in keeping it a strict subset and not allowing our
source trees to diverge. I don't think that will be a problem, but if
it makes you any happier we could put some things in place to try to
guarantee it.

For example, we could mark the source/heimdal/ directory as only being
able to be committed by you. Or we could have a post-commit script in
the heimdal-lorikeet tree that automatically applies any patches to
the common files to the mini heimdal tree in samba. 

I don't actually think either of these measures is necessary, and
instead would suggest the setup I have in my tree at the moment:

 - I have heimdal.lorikeet as a symlink in my samba source directory
   to the lorikeet heimdal tree

 - I run "diff -aur heimdal.lorikeet heimdal | grep -v ^Only.in" to see
   any differences

If we strictly keep our mini heimdal as a true file boundary subset of
the full heimdal then managing the two becomes very easy. You won't
need to carefully merge patches, as you know that any differences
should come across, so 'cp' is your patch tool. For example:

  tar tzf heimdal-mini.tgz | egrep -v '/$' | cut -d/ -f2- > heimdal_list.txt

now I have a list of all common files in heimdal_list.txt. We can
commit that into the samba4 tree if you like. To update to the latest
from heimdal lorikeet I do:

  cat heimdal_list.txt | xargs -i cp heimdal.lorikeet/"{}" heimdal/"{}"

then you commit like this:

  cd heimdal && svn commit -m 'merged heimdal updates'

It really is not painful at all! 

The situation would be totally different if we couldn't work at a
strictly whole file granularity. That is where the difficulty in
maintaining two trees come in, as it requires real work to do a

 > Finally, given the inevitability of a few extra patches, I want to be
 > able to run the 'make check' from my not quite intact Heimdal, and know
 > I've not blown anything up.

I don't see at all why extra patches as compared to the lorikeet
heimdal would be necessary. The lorikeet tree remains as the staging
area for heimdal work in Samba, just like it is now. It also sill gets
built on the build farm, and is kept as a strict superset of the
source/heimdal/ tree.

Cheers, Tridge

More information about the samba-technical mailing list