On Sat, Aug 29, 2009 at 01:59:52PM -0300, David Bremner wrote:
> As discussed on IRC, I got pristine-tar support working using a
> hook. The hook uses the variables DEB_DIR, DEB_SOURCE, and
> DEB_VERSION. It also duplicates the calculation of the orig.tgz file
> using "${DEB_SOURCE}_${DEB_VERSION%-*}.orig.tar.gz".
We should export the latter as DEB_ORIG or so, I saw you'd probably
get bitten by that one when we talked about it yesterday, but figured
I'd wait and see if there were any more you'd need to reconstruct too.
> The not so nice part is I need to know the git directory gitpkg was
> invoked in.
Yeah, that's not so nice on a couple of fronts. But it's a good point
to note, since it highlights one of the (now broken) assumptions of the
original hook mechanism -- that you'd run it to pre-process the exported
source. I hadn't planned for that to perform additional operations on
the repo itself. Mainly I had figured it would be used for things like
removing parts of the tree that were under revision control but should
not be distributed in release tarballs (maintainer tests et al.) or for
pregenerating things that aren't under revision control, but should be
in the release tarball.
Having to hunt your way from the exported source back to the repo again
seems like an ugliness worthy of more major surgery...
> So have a line like the following
>
> REPO_ROOT=$PWD/`git rev-parse --show-cdup`
>
> in my gitpkg.conf. I don't really like depending on the config file
> quite so strongly. It would be great if you could make variable for
> hooks to use that either does what I wrote above, or at least stores
> the $PWD when gitpkg is invoked.
Since what you really want to do here is run a hook _in_ the repo,
probably we should just give you that option, with some clearly
defined rules about when and where it is run ...
So, looking at this under the new light you've shone on it, I see
four interesting places where we might let people stick their fingers
in the cogs of automation at their own risk:
A PRE_HOOK:
This would run in the TLD of the repo, prior to any export being
performed. This isn't the hook you're looking for, since we have
no knowledge of the package version et al. at that stage (and I
don't really see a clean way to get that), but people could use
this to run sanity checks on their repo (are all files committed
etc.) and make 'last minute' changes to it, such as automatically
applying the debian version tag (which some people have said they
like to have automated also), or updating changelogs etc.
A REPO_HOOK: (better names welcome)
This would run in the TLD of the repo, after the debian branch is
exported. DEB_SOURCE and DEB_VERSION would be available to hooks
run at this point, and this is where you could do things like
invoke p-t to export your orig and so short circuit gitpkg from
creating it for you by a simple export.
A SOURCE_HOOK: (ditto on the name for this one)
This would run in the exported source tree, where the current
HOOK_FILE does (and would simply replace that one). Probably
this should actually be split into separate DEB_SOURCE_HOOK
and ORIG_SOURCE_HOOK, since HOOK_FILE is presently run in both
trees but doesn't give you any clear indication of which it is
currently running in -- at present it's an exercise for the user
to have their own heuristic for that if needed.
A POST_HOOK:
This would be run after gitpkg has done all its stuff and the
source package has been created. (probably in the dir where the
source package itself exists?) We could make a DEB_DSC variable
available to this hook which people could use to automatically
invoke cowpoke/sbuild/dcmd $whatever at the completion of the
export. Some people have asked for that functionality too, and
while it's trivial to wrap gitpkg to add that, it seems like a
fairly logical completion of the set if we're now providing
finer grained hooks with some eye to established use patterns.
> I just noticed that gitpkg only works
> when invoked from the repo root directory, so you might consider using
> the "git rev-parse --show-cdup" trick to change there invoked from
> e.g., ./debian
Yes, that seems like a sensible enhancement to make. Cheers.
> Hook and config attached; distributed either or both as you please.
Re your followup about making the p-t hook 'global': If you're
going to do that, then it probably also needs some check for
whether there really is p-t support in the repo that gitpkg is
acting on. gitpkg is intended to be able to work on pretty much
any random repo that has valid debian source in it, so while
assuming all your current repos have p-t support in them might
be 'safe' on the repos you use today, that may well bite you if
I was to, say, get you to pull the gitpkg source and build a
local package to test the changes we make for the stuff above :)
Other than that, this shouldn't be too hard to support a bit more
cleanly and flexibly by the look of it. Let's kick about the
definition of the hooks above, and if we can't see anything we're
still missing in that, then I'll get a new release out with these
changes included.
Thanks!
Ron
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
