On 25 May 2012 16:40, Ron <[email protected]> wrote: > 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?
The problem with doing it from a hook is that I don't want to do the exact same action every time I run gitpkg. For example: * Sometimes I just want to check out the source code. * Sometimes I want to do a binary build (e.g. for Debian upload). * Sometimes I want to do a source only build (e.g. for Ubuntu PPA upload). * Sometimes I want to do a binary build in a schroot of my choosing. * Sometimes I want to do a binary build in a schroot of chosen by package. * I might want to run Lintian on the result. * etc These builds will create files that can conflict with each other. So for the Ubuntu PPA upload for example, I have a script that will create a temporary directory, copy/checkout everything into this directory, build a source only package, upload it to my PPA, and then delete the temporary directory when finished. While building a source only package is a useful action, I wouldn't want to build a source only package every time I do an export. So I wouldn't want to make it a permanent configuration change. In fact, I could be doing a full binary build at the same time in another window - changing a global setting could upset other processes already running. If I could specify the value for DEB_DIR *and* gitpkg.exit-hook from my script, I think I would be mostly happy. > 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. There seem to be two types of hooks: type A: Those that are required to correctly build the source package, e.g. pristine-tar, quilt-patches. These vary depending on the package being built, and as such, having them as git config settings makes perfect sense. They should get executed every time gitpkg is called, regardless of who/what is calling it. type B: Those that do extra things after the source code has been built, e.g. building the binary packages, lintian checks, etc. These should not be run when gitpkg is invoked from a script, and the exact requirements may vary with every run. > 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. Something like: TMPDIR=$(mktemp -d) trap "rm -rf -- '$TMPDIR'" EXIT HUP INT TERM DEB_DIR=$TMPDIR gitpkg $VERSION cd $TMPDIR/blah/blah debuild -i -S -uc -us dput ppa-natty:brian-microcomaustralia/django blah_source.changes (the last three lines could go into a gitpkg.exit-hook hook) > 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. As explained about, some repositories will need the right hooks setup (type A), however these shouldn't affect any automatic scripting. What might be a problem is if there is a type B hook that does something that is relied on by a calling script. Or does something that is not expected. In a practical sense, I suspect type B hooks will always (?) be gitpkg.exit-hook, and as such, if the calling script can override this value it can have control over what happens. I hope this explanation helps :-) -- Brian May <[email protected]> -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
