On Sun, Aug 30, 2009 at 03:25:28PM -0300, David Bremner wrote:
> Ron wrote:
> >On Sat, Aug 29, 2009 at 01:59:52PM -0300, David Bremner wrote:
>
> >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
>
> I wonder if most of the things you mention will need DEB_SOURCE and
> DEB_VERSION? I guess at least the "git status" check could happen
> here, and some people obviously want that.
The PRE_HOOK is the only place where having them available is
troublesome. I'd originally though you could hook in the p-t
stuff there, but we get those two from the debian/changelog
entry that was exported with the treeish you gave gitpkg, so
we'd have to do some fancy dancing to get that before we do
the initial export. Probably not impossible, but I'm not sure
there is a real benefit to the extra complexity there.
I'm willing to be proved wrong if someone can come up with a
use case to warrant it though. Mostly I figured this stage
would be for "pure" repo operations though ...
> >A REPO_HOOK: (better names welcome)
> >This would run in the TLD of the repo, after the debian branch is
> >exported.
And that's why we have this one. Still in the repo at this stage
but after anything that may change the repo in ways that you also
want to export have occurred. And we have DEB_{SOURCE,VERSION}
et al. available to use at all points from here on.
> I thought about namings more suggestive of the sequencing of things,
> but I think it doesn't matter much, and the next two could be in
> parallel anyway.
>
> >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
>
> If understand right, the ORIG_SOURCE_HOOK would not be run in the case
> of re-using a tarball. This makes sense, but might be worth documenting.
> I agree that running the same hook twice is suboptimal.
The main reasoning for the existing situation is that if you want to
remove files or so, then you probably want them removed from both the
orig dir and the debian dir. If you're reusing the orig tarball, then
obviously you don't need to remove them again from that dir copy.
You're correct in your understanding though, and that it should be
clearly documented for the operation of the new hooks.
> >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.
>
> pristine-tar does nothing if it cannot find a pristine-tar branch, so
> it currently prints an error, and falls back on exporting as before.
> I can certainly improve the error checking in the hook (see attached),
Warning at least seems sane. I guess it's kind of up to the local user
as to whether they want that to be fatal (because they know they want
p-t and need to fix something if it didn't work), or not (because they
know they have some repos without it).
> but this brings up the broader question of whether errors in hooks
> should abort gitpkg. Presumably this is what people who want a
> git-buildpackage style "abort-if-dirty" hook would want. I guess hooks
> should just call 'exit 1' if that is what they want?
Yes, I was thinking that some of the sanity checking type hooks might
indeed want to abort the run (or even interactively query the user
about what to do in some case). Calling exit would do that right now,
but if we're going to encourage that, then probably we should catch
the return value in a subshell or so, and do some cleanup for them,
otherwise aborting like that will possibly leave you with the temporary
export and other cruft that hooks shouldn't really have to care about.
> One more comment, it might be nice to accept these variables from the
> environment, so at least for testing people can do
>
> PRE_HOOK=${HOOKS}/dirty-tree.sh gitpkg master upstream
Yeah, though if we do that it might get tempting to just add some
command line options for overriding those things instead. At least
that way you wouldn't accidentally override them with a dirty env.
I kind of like the minimalism of having no options at all but the
treeishes that you want to export, but if that gets in the way of
usability then it's no longer a 'feature'...
Ron
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
