Re: Of the use of native packages for programs not specific to Debian.
Jonathan Yu <jonathan.i.yu@gmail.com> writes:
> 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.
But that is because you have 2 seperate repositories. One for upstream
and one for the debian perl team. You are upstream but the debian-perl
team is the maintainer. That you are also a member of the debian-perl
team is just a coincidence muddying the waters. So I don't think your
case falls under the upstream == maintainer case.
>> 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.
If upstream == maintainer then why would there ever be an upstream
release without a debian release? If you have done all the work of
fixing bugs or adding features and released a new version then running
debsign + dupload is really not complicated. I would assume people
would always do that for releases. Maybe not for dev snapshots, they
might just be for testing prior to uploads. But then those should be
clearly recognisable as such. It takes verry little effort to use a
clear versioning scheme.
MfG
Goswin
Reply to: