On Sun, Oct 22, 2017 at 12:28 PM, Guido Günther <a...@sigxcpu.org> wrote: > Hi, > On Sun, Oct 22, 2017 at 11:15:20AM +0200, Michael Stapelberg wrote: >> Thanks for filing this. >> >> On Sun, Oct 22, 2017 at 9:21 AM, Guido Günther <a...@sigxcpu.org> wrote: >> > Package: pk4 >> > Version: 2 >> > Severity: wishlist >> > >> > Hi, >> > it would be nice if pk4 would allow to use "gbp import-dsc" to unpack >> > the donwloaded sources in downloadDSCAndUnpack so users: >> > >> > - get a git archive right away >> > - can reuise their gbp configuration such as the configured builder, >> > - pristine-tar, ... right away >> >> I think we could introduce a hook which would replace the default >> behavior of dpkg-source -x, taking as arguments the path to the DSC >> and the destination directory. > > Sounds good. > >> >> I wonder whether the gbp hook should live in the git-buildpackage >> Debian package, though? That way, you could maintain it directly. If > > Sure. It would be nice if setup for users would the be as simple as > > ln -s /usr/share/doc/git-buildpackage/examples/pk4 ~/pk4/pk4.deb822.d/gbp
Almost: mkdir -p ~/.config/pk4/hooks-enabled/unpack/ ln -s /usr/share/pk4/hooks-available/unpack/gbp \ ~/.config/pk4/hooks-enabled/unpack/ Regarding the symlink target, could we ship /usr/share/pk4/hooks-available/unpack/gbp in git-buildpackage? That way, all hooks would be in the same directory. This is similar to how shell tab completion files are shipped. > >> you think that’s not a good idea, could you suggest how the hook >> should be implemented? I’m envisioning something like this (untested): >> >> #!/bin/sh >> set -e >> mkdir -p "$2" >> cd "$2" >> git init >> gbp import-dsc "$1" > > #!/bin/sh > set -e > gbp import-dsc "$1" "$2" > > is enough (gbp will do the rest). That way we could also support > incremental imports (that is if the directory is already there we simply > import the new version on top of it so the use can diff between the old > an new version. Note that the pk4 output directories contain the version number, so I think incremental imports wouldn’t work well. > >> Side note: I think we should be fairly clear about the difference >> between a gbp-from-dsc repo and a gbp-from-gbp-clone repo, to not >> confuse our users. > > Yeah. I was thinking of putting a .git/gbp.conf into the repo that sets > > [DEFAULT] > upstream-branch = upstream > debian-branch = pk4 > > This would > > - make sure we override settings any branch settings in debian/gbp.conf > which we don't care about (since we're not cloning from Vcs-Git: > - Having the default branch named pk4 would make it obvious that this > is s.th. special. > > What do you think? In this case it would rather be more like your script > above: Sounds good to me. > > #!/bin/sh > set -e > > if [ ! -d $2 ]; then nit: use "$2" here as well > > git init "$2" > > cat <<EOF > "$2"/.git/gbp.conf I suggest to add as a comment what you wrote above for the benefit of readers of the hook :). > [DEFAULT] > upstream-branch = upstream > debian-branch = pk4 > EOF > fi > > cd "$2" > gbp import-dsc "$1" > > > Does this sound reasonable? I would then also provide a script that can > be used with pk4-replace. I don’t quite follow. What sort of script is required for that? > > Cheers, > -- Guido > >> >> > >> > Cheers, >> > -- Guido >> > >> > -- System Information: >> > Debian Release: buster/sid >> > APT prefers testing >> > APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, >> > 'testing-debug'), (500, 'stable-updates'), (500, 'oldoldstable'), (500, >> > 'unstable'), (500, 'stable'), (1, 'experimental') >> > Architecture: amd64 (x86_64) >> > Foreign Architectures: i386 >> > >> > Kernel: Linux 4.13.0-1-amd64 (SMP w/4 CPU cores) >> > Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), >> > LANGUAGE=en_US:en (charmap=UTF-8) >> > Shell: /bin/sh linked to /bin/dash >> > Init: systemd (via /run/systemd/system) >> >> >> >> -- >> Best regards, >> Michael >> -- Best regards, Michael
