Re: Of the use of native packages for programs not specific to Debian.
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-v-b@web.de> 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
>>> 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-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
>
Reply to: