On Sun, Apr 04, 2010 at 11:06:34PM +0200, Reinhard Tartler wrote:
On Sun, Apr 04, 2010 at 21:29:21 (CEST), Jonas Smedegaard wrote:Very well. I will have a look at implementing such hack, then.How about this:
diff --git a/debian/rules b/debian/rules index bf5eb38..5886dcb 100755 --- a/debian/rules +++ b/debian/rules
When there's a debian/rules.in (as is the case here) then please edit that one instead.
When the clean rule is executed while DEB_MAINTAINER_MODE=1 in the environment, debian/rules is autoupdated, resolving build-dependencies related to included CDBS snippets. I always do that right before release, so will then discover and reapply if someone like you here had edited debian.rules drectly.
@@ -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.
debian/stamp-waf-configure: waf configure --prefix=/usr $(MIXED_FLAGS) --firewire --alsa --classic --dbus touch $@ -clean:: +clean:: unpatch rm -f debian/stamp-waf-configure
I 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 +Also, 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...
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-patch
Why? I would consider autogenerated patches an error anyway, so do not care about its naming.
Yeah, true. That one piece is Perl. And I really should merge that script into licensecheck itself. Just haven't taken the time and social endurance yet to figure out how that package is maintained, whom to discuss with if ok that I start hack on it to improve it, and how many different opinions I need to challenge and argue against regarding Perl coding style, intend of that tool etc. etc. etc.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. Please bug-cc me, as I would like to actually do the job of cleaning up licensecheck, if the opportunity is there. It is a little baby of mine, that DEP5 compliant licensecheck output. :-)
Just see how much time we've spent arguing about packaging style here. No, I am not whining, just stating the fact that it takes time and effort to get involved in yet another development team.Oh, I don't think this time is wasted, as long as we don't restart it over and over again.
Agreed. I carefully avoided the term "wasted" in my text above ;-)
However, we mustn't forget to add our conclusions to http://wiki.debian.org/DebianMultimedia/DevelopPackaging
Hmm. 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?
So that one hack is Perl but irrelevant for dkpg-dev. And other parts are not Perl so irrelevant for dpkg-dev too. As I see it.As for the repackaging tarball functionality, from the first glance I also think it could probably live in devscripts as well; conversion to shell seems really straight forward.
Hm. Right you are.Again, I fear the unknown, and who is governing devscripts is unknown to me. You are most welcome to help break the ice, by filing bugreports, holding my hand, or tell me the cold facts of how that package is maintained... :-)
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
Description: Digital signature
_______________________________________________ pkg-multimedia-maintainers mailing list email@example.com http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers