On Sun, Apr 04, 2010 at 09:44:48AM +0200, Reinhard Tartler wrote:
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.
Good point!
Is it really too much that simple things like 'build && clean' leave a 'clean' working directory?!
I believe that I could make a CDBS snippet that cleans up patches and .pc dir at clean time when in a git.
Applying the patches at build time should not be necessary, as dpkg handles that itself.
Such snippet - like most of CDBS - would *not* depend on CDBS managing debhelper too, so should be usable also together with short-form debhelper v7.
I believe that would help the point of usability, as then only once initially something odd would need doing. Would that be interesting?
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.
Makes sense. Above proposed snippet would only be a temporary measure until underlying tools evolve further.
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.
Good point! Thanks.
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?
It seems to me that dpkg-dev is Perl-based. CDBS is make-based, so as I see it dpkg-dev could adopt ideas only, not actual implementation.
Unless you propose dkpg-dev to be extended to also act as a "cdbs-core" which I suspect is unlikely to happen - but maybe that's just me being narrowminded...
In other words: Please elaborate. And I strongly suggest you to do that as a wishlist bugreport against dpkg-dev (adding build-common-hack...@lists.alioth.debian.org as bug-cc) rather than here.
Kind regards, - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: Digital signature
_______________________________________________ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
