[SCM] Debian packaging for jack-audio-connection-kit branch, master.jackd2, updated. debian/1.9.4+svn3842-2-41-g15d16a4

[Reinhard Tartler]

On Sat, Apr 03, 2010 at 13:14:41 (CEST), Jonas Smedegaard wrote:

> First it was claimed that git-buildpackage did not work with the new
> source format.  [...]
> Here you raise the more relevant concern if the new format is beneficial
> or brings mors hassle.

git-buildpackage defines a couple of workflows that differ from
Format 1.0 to Format 3.0 (quilt), so my objection still stands.

> I certainly believe it it beneficial (and from that bugreport I get the
> impression that Colin feel the same - it is just a _wishist_ bug and he
> introduces by higly prising the new format in general):

I'm already sold to the new format for any package that is not
maintained by a VCS, no need to convince me of that. Really, my
objection is that adding new, contradicting workflows with the same tool
that depend on the format is not really something that I want to impose
on a team with members of different skill levels.

>  As I believe I wrote already in an earlier response, those wanting
> things as simple and automated as possible have several options:
>
>   1) request git-buildpackage to do the build in a separate directory
> to not mess with the Git tree

*sigh*. This reminds me of the pain svn-buildpackage created with this
 horrible mergeOnUpstream feature.

Is it really too much that simple things like 'build && clean' leave a
'clean' working directory?!

>   2) tell Git to ignore the .pc directory, and instead of invoking
> "debuild clean" instead invoke "debuild clean && quilt pop -a".
>
> If 2) is the preferred way, but still too much hassle, I would be happy
> to help design a smapp debuild wrapper script that seemlessly a) removes
> .pc dir if only containing dotfiles, and b) unpatches whenever cleaning.
> I would not use such script myself, because (as I wrote above) I happen
> to use it as a feature, no matter if that was the intend of it :-)

And I demand that this wrapper script gets integrated into
git-buildpackage, so that simple operations like cleaning and "build and
clean" leave the working directory in a clean state.

> Perhaps you would be interested in gbp-pq, added recently to
> git-buildpackage.
>
> More information here (as mentioned in its manpage):
> https://honk.sigxcpu.org/piki/development/debian_packages_in_git/
>
> I have not used it myself (I am sceptical to the dynamic generation of
> patches) and suspect that it won't solve the noise with dpkg format 3.0,
> so just a side note...

Not by itself, but I think that this mechanism could be a building block
for that. I like that it uses debian/patches as exchange format, but
internally imports the patches as proper commits.

Unfortunately, it wraps simple git commands and provides wrappers like
gbp-pull, git-quiltimport, etc. I suspect that git, unlike bzr, doesn't
provide replacing or extending existing commands, which I find a bit
unfortunate. But I'm not insisting on that. As long as the workflow for
Format 1.0 and Format 3.0 (quilt) patches remain the same, i.e., the
same tools work the same on Format 1.0, we don't need two separate
versions of the wiki page DevelopPackaging.

>>> Am I free to not find it silly?  As part of this team?
>>
>> I'd very much prefer to work on a consistent set of packages. Having
>> some packages maintained in this and some in another way leads
>> individuals to look and care only after a subset of our team's
>> packages.
>
> Hmm.  Then perhaps I already do not fit in and should go solo again: I
> push the use of CDBS which already divides the packaging in two camps,
> and also have strong opinion on the use of pristine sources.
>
> What do you think?  What do others think?

Side note, I see that there are some really interesting cdbs make
snippets, e.g., the upstream.mk rules etc. I understand that they are
still pretty much in flux. Could you imagine to propose a stabilized
version (or a subset of them) for dpkg-dev?

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4