[Build-common-hackers] waf.mk and broken fakeroot debian/rules clean call in packaging-only branches.

[Krzysztof Klimonda]

On Tue, 2011-03-29 at 02:04 +0200, Jonas Smedegaard wrote:
> On Tue, Mar 29, 2011 at 01:14:38AM +0200, Krzysztof Klimonda wrote:
> > I've worked today on the update for hamster-applet and, as the 
> >upstream has switched to waf, I've opted to use a waf.mk class from 
> >cdbs.
> >
> > Unfortunately including it in debian/rules breaks fakeroot 
> >debian/rules clean call that I (and probably other GNOME maintainers) 
> >use to generate debian/control from debian/control.in. Now waf.mk tests 
> >for the existence of $(DEB_SRCDIR)/waf file, and stops process when 
> >it's missing - we keep only packaging in subversion, so both waf and 
> >wscript files are not there when d/rules clean is called.
> >
> > I've tried changing the order of include lines, to move waf after all 
> >other files, but it didn't help.
> >
> >Any idea what could I do to make it work, or maybe I miss something 
> >obvious?
> 
> Hmm.  If I understand you correctly, you are trying to make your 
> packaging routines sanely not only with the full source available but 
> also when only the debian subdir - not all source - is available?

Thanks for the quick answer.

Yes, as far as I know all packages maintained by the pkg-gnome team are
store this way - only debian/ subdirectory is kept in the repository,
and you don't get the entire source tree upon the checkout. You can the
use svn-buildpackage instead of debuild/dpkg-buildpackage to create
source or binary packages.

> Sorry, I can't help you there.  You might have luck that some packaging 
> style works out like that, but it is not a kind of situation that I have 
> ever taken into account before, nor do I find is likely that I'll do it 
> in the future (but you are very welcome to try convince me otherwise!).

Thanks, I can try. :)

> Seriously: I do not mean to end the conversation here - just warn you 
> that I expect it to need not only restructuring of code but also quite 
> some convincing to solve this issue - or clarification if I simply 
> misunderstood what is the real issue.

I think almost all packages maintained by the pkg-gnome team have, in
the d/control header, statement that d/control is being generated by the
clean target, and should not be edited. So the d/rules clean has to be
ran every time someone wants to update this file.

As far as I know none package stores entire source tree in the pkg-gnome
svn repository, and the majority of them are using cdbs.

I can only assume that, as the problem seems new to you, the issue of
d/rules clean not working has never been raised here. So it means that
either all other maintainers are copying full source to the packaging
branch for the duration of work, only to remove it before commiting
changes, or it has always worked this way for other packages, and waf.mk
does things differently.

In my opinion, if a single tool [1] in a suite behaves differently from
others, without a good reason, it's broken.

> > PS Please keep both me and Rémi in CC as we are not subscribed to the
> > list. Thanks.
> 
> Hmm - no Rémi was cc'ed so I just cc'ed you this one.

Hmm.. I wonder why, I can see him in the CC field of the message source,
maybe the letter é has broken something? . He's listed in the waf.mk
file as one of developers who's worked on it. Let's see if it works this
time.

Regards,
  KK

[1] It's possible that waf.mk is not the only tool/class in cdbs that
doesn't work without full source in the directory - I'm not that
familiar with cdbs to be sure of this statement. If it's the case, then
it still puts additional work on maintainers' shoulder to keep track of
what works, and what doesn't.