I agree that debian/ files likely don't cause a "whole lot of trouble" to us (it should only be a line to remove it using debian/rules prior to building? but I'm not 100% sure on that). However, I don't think that it not being tremendously burdensome on us in Debian is sufficient justification to permit or encourage this behaviour.
On Wed, Sep 16, 2009 at 4:41 AM, Goswin von Brederlow <goswin-...@web.de> wrote: > Wouter Verhelst <wou...@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 >>> problems >> >> I 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 am both the upstream maintainer of several Perl modules, for which I am also one of the Debian package maintainers. I personally am just pragmatic, and provide only what is necessary at various points -- so, upstream packages contain what is necessary to install via the standard Perl-ish way (CPAN shell), and the Debian packages contain this plus some Debian-specific stuff. One of the issues I would have with putting debian/ files upstream (beyond just being unexpected by the user since it's probably very uncommon in the wild) is that I would need to sync changes that the other pkg-perl team members submit, since we maintain packages as a team. It just seems a whole lot of work for little gain. > > 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. > >> Debian packages from the Debian distribution usually are >> policy-compliant and maintained, so this kind of problem does not >> manifest itself as often for our downstreams > > And as we were talking about packages where the debian maintainer is > also upstream this problem also doesn't manifest for Debian itself. > >> (of course there are packages that are not maintained nor >> policy-compliant, but then they don't tend to live long in the >> distribution). And the problem is that users really don't know which is which, so upstream is just being a jerk and confusing their users :). Not to mention that it would reflect badly on our packages in Debian, as people would say, "damn Debian packages, this one wouldn't even build, it sucks!!!" I think someone (tm) should do a study and see just how difficult it is to deal with debian/ files in an upstream tarball. I take it that our scripts probably handle this sort of thing transparently, or that the effected files are removed prior to build time. > > MfG > Goswin > > > -- > To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > > -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
