Re: upstream supports debian: wtf?

[Adrian Bunk <bunk@fs.tum.de>]

On Wed, 6 Jun 2001, Domenico Andreoli wrote:

> after a nice discussion on irc and some mail exchange with some upstream
> developers it rised that there is no a well defined behaviour a debian
> maintainer should keep in this particular situation.
>
> in particular:
>
> 1) it is not so clear when native packages should be used instead of the
>    standard plain ones
>...
> 3) policy do not cover anything of the above points (should this be covered?)

That's not true. Policy says in 4. Version numbering:

<--  snip  -->

     <debian_revision>
...
          It is optional; if it isn't present then the <upstream_version>
          may not contain a hyphen.  This format represents the case where
          a piece of software was written specifically to be turned into a
          Debian package, and so there is only one `debianization' of it
          and therefore no revision indication is required.
...

<--  snip  -->


> beware that these points implicate more than what seems at first sight, some
> of them follows. please feel free to add others as required.
>
> 1) a) using native means that debian maintainer is not so free to make all the
>       uploads he thinks are required and that every debian release is also
>       an upstream release
>    b) any little variation in debian files required to make a good native package
>       means that on *every* upload we are moving all the sources and not only
>       modifications, which is the point in using .diff.gz for debian files and
>       modifications
>
>    *note*: i'm not talking about native packages made ad hoc for debian (like
>    dh-make and many other)! i'm considering legal to make native packages also
>    when upstream != debian maintainer, policy doesn't forbid this assumption.
>    developer reference talks about native vs. plain packages, but it seems
>    somewhat outdated (wiggy, correct me if i'm wrong)
>...


Yes, it's legal to make it a native package.
But consider the following cases:

1. Upstream must release a new version to fix a missing build dependency.

2. When we are in a freeze and you have to do an upload only to frozen
   (because there's a newer version of the program already in unstable)
   upstream has to branch it's development and must release a version
   based on the version that is in frozen.


cu
Adrian

-- 
A "No" uttered from deepest conviction is better and greater than a
"Yes" merely uttered to please, or what is worse, to avoid trouble.
                -- Mahatma Ghandi