Goswin von Brederlow wrote:
Wouter Verhelst <wouter@debian.org> writes:On Mon, Sep 07, 2009 at 11:22:30AM +0200, Giacomo A. Catenazzi wrote:We have a lot of troubles when upstreams ship a debian/ directory in upstream tarball, thus I'll expect derivatives will have similar problemsI don't see it that way. The reason why we have 'a lot of troubles' when upstreams ship a debian/ directory, is because upstreams usually supply that directory as a courtesy to make life 'easier' for those people who want to build a Debian package out of their SCM repository, and that as a result, they are usually not even remotely Policy-compliant. Thus, we need to do a *lot* of work to get them integrated properly; and any files that keep lying around in debian/ might interfere with other things.And that quickly goes away when upstream accepts patches that fix their debian directory. I don't see that as a *lot* of work at all. It just means you need a good relationship with upstream so changes to the debian dir are merged upstream quickly. If you have write access to upstreams RCS then I don't see this as a problem at all.
Yes, but I use cdbs for my packages, and I don't want to force upstream to use the same tools. But now I've found an other problem: On native package the debian/changelog is also used for upstream changelog: upstreams tend to package their packages as native. But I'll pack it as normal package. With the 3.0 source format the upstream changelog (if it is in debian) will be removed (which could maybe is a problem with the GPL licenses: we distribute in the sources the changelog, but we hide/delete it, when unpacking). Thus non debian specific package, which are also native, should (must on GPL licensed packages) have a separate "upstream" changelog. ciao cate