On Mon, Apr 05, 2010 at 10:39:55AM +0200, Reinhard Tartler wrote:
On Mon, Apr 05, 2010 at 00:34:47 (CEST), Jonas Smedegaard wrote:@@ -3,6 +3,7 @@ -include /usr/share/cdbs/1/rules/upstream-tarball.mk include /usr/share/cdbs/1/rules/utils.mk include /usr/share/cdbs/1/rules/debhelper.mk +include /usr/share/cdbs/1/rules/patchsys-quilt.mk include /usr/share/cdbs/1/class/makefile.mk...because adding above cause the package to need to build-depend on a few additional packages.quilt, yes. is this a problem?
No no, just trying hard to sneak in an advertisement for another feature of CDBS.
...and no, it is not inly quilt it adds build-dependncy on: Try autoresolving and see:
DEB_MAINTAINER_MODE fakeroot debian/rules clean git diff debian/controlHmm - and while writing this I get an idea for an improvement to CDBS: build-depends-reason hints! Now that recently I've managed to handle each set of added build-dependencies as a separate chunk and only merge when applying, it should be possible to add hints explaining the reason for each chunk (e.g. point to specific places in Debian Policy, Debian Python Pilicy, Python Policy, Perl Policy etc., and print those hints when in DEB_MAINTAINER_MODE. Maybe even detect which are _newly_ added and treat them as *error* when in DEB_MAINTAINER_MODE to raise awareness.
debian/stamp-waf-configure: waf configure --prefix=/usr $(MIXED_FLAGS) --firewire --alsa --classic --dbus touch $@ -clean:: +clean:: unpatch rm -f debian/stamp-waf-configureI recommend to keep unrelated routines separate, even if it causes the rules file to be slightly larger, and document unclear intends:touch $@ clean:: rm -f debian/stamp-waf-configure + +# Un-apply patches left behind with source format 3.0 (quilt) patches +clean:: unpatch +okAlso, above always un-applies, not only when using git - I am uncertain if that will cause problems somewhere. Not sure waht that might be, just worried...okay, then I'll need to extract some logic from patchsys-quilt.mk
Ah! When I opened my eyes this morning (i.e. a moment ago - I watched movies with my step kids until 5 tonight) I remembered/realized a need for improvement in the above:
When we do clean:: unpatchthen unpatching happens _before_ clean rules. And if parallellism is enabled even the order of those before-clean rules is uncertain.
So we should instead do
clean::
quilt pop -af
and in addition we should a) put that rule at the bottom of the rules
file and b) explicitly set the number of allowed CPUs to 1, both of them
to ensure (as best as we can) that patches are unapplied _last_.
Also, when we use the patchsys-quilt snippet we include not only our own clean-at-build but also patch and unpatch rules that I suspect some build routines may probe and use if found - which is bad as we most probably rely on source being patched early on.
Hmm, maybe we should actually ensure early patching, not just rely on dpkg doing it for us early enough. I have had some odd experiences when invoking build rules expicitly to regenerate copyright hints that it was wrongly done on unpatches source.
While we are at it, I'd suggest this change as well for Format 3.0 packages in general: --- /dev/null +++ b/debian/source/options @@ -0,0 +1,2 @@ +# use debian/patches/debian-changes as automatic patch +single-debian-patchWhy? I would consider autogenerated patches an error anyway, so do not care about its naming.The manpage recommends it this way, as when working in a VCS, the version number, and therefore the file name of the generated patch is meaningless if not wrong. Foring a stable filename ensures that changes go into a single patch.If we consider these autogenerated patches an error, this way we can extend debian/rules to check for existance of this file, and abort with an meaningful error message.
Good point. I am still not sure it is really necessary to add custom configuration, though: I suspect (but haven't investigated yet) that we can simply check for a pattern of autogenerated filenames - or simply check (using a checksum) that the series files does not change underneath us - which might protect against other kinds of automated surprises in the future.
Ok, I think we agree here. Let's start with a wishlist bug against devscripts for licensecheck2dep5. Do you want to file or shall I?Go ahead and do it.See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=472199
Thanks!
However, we mustn't forget to add our conclusions to http://wiki.debian.org/DebianMultimedia/DevelopPackagingHmm. I am unsure what is policy and what is suggestions and what is my stubbornness in what we've discussed here - so please you do that, ok?Well, that's the problem. Now that we allow both cdbs and debhelper, both format 1.0 and 3.0 patches, the page now becomes terribly convoluted. I fear we need more discussion to streamline what we actually want.I could imagine that we agree on a default workflow, which is applied to all packages but exceptions, and list the excepted packages there.
Fair enough. I have now subscribed to changes to that wiki pages, and am willing to help maintain it.
Please do ping me explicitly, though, if there are some things you feel the need for me to edit or for us to discuss, as I am involved in maintenance of 100+ packages and (try to) have a life aside too :-)
Or expressed differently: I am a bit of a lonely rider if not pushed into other workflows. Please help push me from time to time :-)
- 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
