On Wed, 2008-07-16 at 16:40 +0200, Nils Philippsen wrote:
> On Mon, 2008-07-14 at 10:53 -0400, Doug Ledford wrote:
> > We do this internally now for the RHEL4 and RHEL5 kernels. The kernel
> > maintainer has a git repo, we work from that repo, we send patches to
> > the maintainer internally, they commit to the repo, then come build
> > time, they spit out a tarball and a set of patches to import into CVS
> > and then the build happens from CVS. It's cumbersome, and it introduces
> > a few problems in that if you make a patch that touches file that are
> > part of the git repo itself, but not part of what you want exported to
> > the CVS checkins (such as patches to the scripts that generate a tarball
> > and patches from the git repo), then those have to be filtered out
> > before you check things into CVS etc.
>
> Heh, but these parts should have been put elsewhere in the first place,
> don't you think ;-)?
Not necessarily. The custom Makefile in the kernel cvs repo does some
magic to massage certain files before building (like the vast array of
kernel config files that it generates from a hierarchy of config
settings). The sources for that massaging are part of the cvs repo, and
they should also be a part of the git repo. But, because we don't use
them in directly in the spec file, nor massage them directly in the spec
file, they get excluded from the srpm, so if we allow git patches that
touch these files to get automatically exported as patches for the srpm
to use, they end up not applying to anything and break. On the other
hand, we very well need those patches to be applied to the gunk that's
in CVS but *doesn't* become part of the srpm. It's just a mess.
--
Doug Ledford <dledford@xxxxxxxxxx>
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
Infiniband specific RPMs available at
http://people.redhat.com/dledford/Infiniband
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
