Re: [Quilt-dev] patch for alternate setup mode

[Brian J. Murrell]

On Thu, 2006-02-09 at 00:47 +0100, Andreas Gruenbacher wrote:
> Hello Brian,

Hi Andreas,

> I still don't get it: the setup command currently sets up a source tree from 
> a 
> set of tarballs and a set of patches by untaring the tarballs and creating 
> symlinks back to the patches directory. If a spec file is passed, it 
> additionally figures out which the tarballs and patches are.

Maybe (likely) it's me who doesn't get it in fact.  I'm more than
willing to admit that my only exposure to quilt is as CFS uses it to
patch a kernel with patches required for Lustre.

> If you are working against a cvs tree, how does the source tree get created 
> that you want to have the series and patches links created in? Don't you use 
> a script for creating that tree from the cvs? If it's a script, then why 
> can't that script create the symlinks in the first place, instead of adding 
> some weird options to the setup command?

Well, this is (roughly) what we typically do:

$ cvs co lustre
$ tar xzvf kernel-$version.tar.gz
$ cd lustre
$ ./configure ...
$ cd ../linux-$version
$ quilt -l ../lustre/kernel_patches/series/$a_series_file -d 
../lustre/kernel_patches/patches
$ quilt push -a

Now to further explain, in ./lustre we have this hierarchy:

lustre/kernel_patches/
 \_ series/
     \_ 2.6-fc3.series
     \_ 2.6-fc3-uml.series
     \_ 2.6-suse.series
     \_ 2.6-vanilla.series
     \_ ldiskfs-2.6-fc3.series
     \_ ldiskfs-2.6-suse.series
     \_ ldiskfs-2.6-vanilla.series
     ...
 \_ patches/
     \_ dcache-fid-2.6.7.patch
     \_ dcache-mds-num-2.6.7.patch
     \_ dev_read_only-2.6.10-fc3.patch
     \_ dev_read_only-2.6-suse.patch
     \_ dynamic-locks-2.6.10-fc3.patch
     \_ dynamic-locks-2.6.7.patch
     ...

and in a given series file we will list the patches:

uml-2.6.7-01-bb2.patch
lustre_version.patch
vfs-dcache_locking-vanilla-2.6.patch
vfs-dcache_lustre_invalid-vanilla-2.6.patch 
vfs-intent_api-vanilla-2.6.patch 
...

So when we are done with the the "quilt setup" in the kernel directory
both series and patches are actually symlinks back to the lustre cvs
sandbox.

The benefit to using links here is that any operations on patches and so
on (like a refresh for example) are done in the context of the lustre
cvs sandbox and a resulting cvs command there (diff, commit, etc.) works
on the patches as quilt has modified them while working in the kernel
directory.  This way we don't have to remember to copy patch files back
and forth and so on to get the work back into our CVS tree.

b.

signature.asc
Description: This is a digitally signed message part