On Fri, May 25, 2012 at 09:24:02AM +1000, Brian May wrote: > On 24 May 2012 23:10, Ron <r...@debian.org> wrote: > > Hi Brian, > > Hello Ron, > > Thanks for your very prompt response. > > > Is there anything other than DEB_DIR that you can see your script likely > > wanting to override to do what it needs to do? > > I guess my use case would be along the lines of scripting: > > TMPDIR=... > DEB_DIR="$TMPDIR" gitpkg "debian/$VERSION" "upstream/$UPSTREAM" > cd "$TMPDIR/$SOURCE/$SOURCE-$UPSTREAM" > > This is still a bit non-optimal in that I don't know the $SOURCE value > that gitpkg worked out.
Yeah, DEB_SOURCE is determined by the d/changelog from the debian-ref that you are exporting. You can get at the full configuration, including that, before gitpkg starts to do any Real Work by using a pre-export-hook, but it's not actually known at any point before then. > Not sure what the best solution is here, > ideally I would need the value of "$DEB_DIR/$DEB_SOURCE/$DEB_PACKAGE" > after gitpkg exits. > > Am going to have to think about this a bit more. Maybe a hook could be > used to write the environment variables to a file, that then could be > parsed/sourced caller. Except the hook can't be specified on the > command line. Do you really need this persistently after gitpkg exits, or can you actually do what you need with it from a gitpkg hook before it exits? > Also, if the user has set gitpkg.exit-hook to > "/usr/share/gitpkg/hooks/dpkg-buildpackage-exit-hook" as per > documentation this might mess my script up. Suddenly gitpkg does a lot > more then expected. Not something I need to worry about personally, > for the more general case might be an issue. Right. That's kind of why "correctly building the source package" really shouldn't ever depend on any hooks. Mostly they should be considered "reserved for the local user", who might do anything with them that they please to connect a source package export with *their* other automation, such as running sanity checks or passing the package off to a buildd of their choice etc. We could potentially let you set things like EXIT_HOOK from the environment as well, but there is a playing with fire element to that which we'd probably need to think through carefully as well. Can you give me an outline of what your script needs to do before and after gitpkg does its bit? I really would like to avoid there being anything that is "impossible" to do with it, that isn't already quite impossible for fundamental reasons which have nothing to do with gitpkg. So we've tried to expose most things and let you hook in at all the places where they are first known, or where you might do some action based on them before the next logical step. We haven't really defined a "calling script" configuration interface to date though, mostly because there hasn't been a real life example of such a thing to guide what is needed there. At first glance it doesn't seem unreasonable to let such a script override the git-config settings, since if it wants to respect them, it can read them itself (and if people don't want scripts that don't respect them, they can call gitpkg directly, or fix them so they do). The main thing we should try to avoid is creating a repo where the source package can only be exported correctly from it if you have exactly the right hooks and other scripts to do that configured. But any other higher level operations that do things with the source once exported we should support as fully as it is possible to do. Cheers, Ron -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
