quilt-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Andreas Gruenbacher
Subject: Re: [Quilt-dev] patch for alternate setup mode
Date: Thu, 9 Feb 2006 04:05:36 +0100
User-agent: KMail/1.8.2

On Thursday 09 February 2006 02:00, Brian J. Murrell wrote:
> 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.

Okay, that's roughly what I guessed. So different series files go with 
different kernel tarballs as well, right?

How about this approach: you add ``# Source: ...'' comments to each of those 
series files that identify whatever tarball the series is against (filename 
only; no path); quilt setup already understands those. We add an option to 
the series command that allows to specify an optional additional search path 
for the tarballs.

Then you can do this from the lustre directory:

        quilt setup --path=.. lustre/kernel_patches/series/2.6-suse.series

this will untar the tarball and set up the rest as you want. Add -d and you 
can define where the tree gets created. We only need to make sure that the 
setup command symlinks to the series file if a series file is specified on 
the command line. Makes more sense than the current way of creating a 
duplicate series file as well.

Andreas




reply via email to

[Prev in Thread] Current Thread [Next in Thread]