Re: Of the use of native packages for programs not specific to Debian.
"Giacomo A. Catenazzi" <cate@debian.org> writes:
> Wouter Verhelst wrote:
>> On Thu, Sep 17, 2009 at 07:46:08AM +0200, Giacomo A. Catenazzi wrote:
>>> On native package the debian/changelog is also used for upstream
>>> changelog: upstreams tend to package their packages as native.
>> [...]
>>> Thus non debian specific package, which are also native,
>>> should (must on GPL licensed packages) have a separate
>>> "upstream" changelog.
>>
>> That doesn't follow. You're assuming it's going to be impossible to keep
>> the original debian/changelog file, and/or that the only way to package
>> something that an upstream has packaged as native is to package it as
>> non-native.
>
> hmm. Do you think we should pack an external package as native, if
> upstream (or "upstream distribution") packages it as native?
If you can join the upstream team and do releases directly as the
upstream you then are then why not?
> I think this is not intended by our polict, but OTOH it is the easier
> way: we should only take care about version conflicts (automatically
> adding a suffix could not be enough on few seldom cases).
>
> But if we pack as non-native (as it should be: we are not upstream),
> more problems arises:
> we cannot patch anymore debian directory: on 3.0 source format
> the original debian dir will disappear, thus removing the
> debian/changelog (which is required by GPL for upstream changes).
How does that work at all for upstream itself? From what you describe
unpacking the upstream released source with dpkg-source -x would end
up without debian dir at all.
> It is not impossible to solve this problem: we can manually copy the
> original changelog to our diff/patches.
>
> So the question is:
>
> Is it really worth to use "native package for programs not
> specific to Debian" ?
Is it worth it use non-native when you are upstream and maintainer?
I think that is the more important question. For packages where
upstream != maintainer you should imho not use native format.
If upstream releases debian packages (has a debian dir) and the
maintainer also releases debian packages then there will be
problems. That can only be avoided by close cooperation. Become
co-upstreams / co-maintainers and only release one version.
> I still think it is not nice for downstream.
It is not nice either way. Worse for downstream of downstream.
>> If I'm an upstream and a Debian maintainer for a particular package, and
>> a downstream distribution wants to modify my package, then I think it's
>> fairly reasonable for them to just modify the package, without having to
>> repackage it entirely.
>
> This is the problem with sources 3.0, on non-native packages: we cannot
> modify the package, we must repack discarding all original files in debian/
Why? Only problem I see is that you need to duplicate the files from
debian/ if you change from native to non-native.
The solution is to get upstream to fix their debian dir so you do not
have to modify the package under normal circumstances. And in an
emergency you modify it as native package.
>> People fork software *all the time*. This is no different.
>
> Yes, but it is not our job to fork packages (freely interpreted from devref 3.5).
>
> ciao
> cate
MfG
Goswin
Reply to: