Heimdal Futures

[Andrew Bartlett]

On Wed, 2005-07-06 at 10:31 +1000, Andrew Tridgell wrote:
> Andrew,
> 
>  > 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.

Well, it just means that what is in the repository is identical to what
is in the tarball.  But I suppose it's not that vital...

> To make this debate a bit more concrete, here is what I propose to
> import:
> 
>   http://samba.org/~tridge/heimdal-mini.tgz
> 
> 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. 

This I think would be a useful step.

> 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! 

Possibly :-).  Presumably the build system could extract this
information from the build system.

I need to think about this a bit more, but this makes sense.

>  > 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.

I was referring to a situation where we have a small patch on an
official release, not a patch difference between lorikeet/heimdal and
samba4/source/heimdal

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Samba Developer, SuSE Labs, Novell Inc.        http://suse.de
Authentication Developer, Samba Team           http://samba.org
Student Network Administrator, Hawker College  http://hawkerc.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba-technical/attachments/20050706/3149a845/attachment.bin