Re: [PATCH 0/3] cogito spec file updates
- From
Petr Baudis <pasky@ucw.cz>
- Date
- May 3, 2005, 21:21 UTC
- Message-ID
- <20050503212142.GB15995@pasky.ji.cz>
- In-Reply-To
- <20050503193536.GE5324@shell0.pdx.osdl.net>
Dear diary, on Tue, May 03, 2005 at 09:35:36PM CEST, I got a letter where Chris Wright <chrisw@osdl.org> told me that...
Show 10 quoted lines
> * Chris Wright (chrisw@osdl.org) wrote: > > Here's the outstanding updates for the spec file, up to 0.8-2 which is > > the latest on kernel.org. > > > > http://www.kernel.org/pub/software/scm/cogito/RPMS/ > > What's your method for creating a release tarball? If it were formalized > (i.e. Makefile rule), then it'd be simple to use VERSION to drive the > spec file, and it'd only need updating for real content changes (similar > to what Kay did).
For now, I do it so seldom that I just manually do
cg-log >Changelog cg-export ~/cogito-0.9 cp Changelog ~/cogito-0.9 cd ~ tar cvvfz cogito-0.9.tar.gz cogito-0.9
OTOH, I'd like to change this all to just
cg-export ~/cogito-0.9.tar.gz
when I get to merge the relevant patches; I'm not sure there is so much of a value to bundle the Changelog; just get the git tree and do cg-log on your own, or use the web interface.
I might however have some private mkrelease.sh script which would do
echo "$1" >VERSION update-spec-file echo "$1" | cg-commit cg-tag "$1"
or something.
BTW, did you have a particular reason to split the .spec file updates to three parts? I think it doesn't make much sense and it'd be probably enough to update it at once, when we are not doing it at the right time anyway.
-- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor