[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: native packages

On Tuesday 23 January 2007 12:37, Thijs Kinkhorst wrote:
> On Tue, 2007-01-23 at 21:34 +1100, Andrew Donnellan wrote:
> > What exactly are the advantages and disadvantages of making a
> > Debian-native package, and is there any real policy or practice?


> I think this is a good rule:
>         If the source is published outside of Debian,
>         do not make a native package.

This is true, but I like that wording best: Policy#5.6.12 [1] 
[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 "debianisation" of it and therefore no 
revision indication is required.

> The disadvantage of a native package is that there's no clear
> separatation of what is upstream and what changes are made by Debian.
> There's no clear advantage of using a native package as far as I know.
> You only use a native package when there just isn't such a thing as an
> upstream tarball (i.e.: there is no upstream, the package is only
> developed within Debian).

Right. Another disadvantage of making it a native package is that the
orig.tar.gz (imagine monsters here, ... OpenOffice.org comes to mind ;-) has 
to be uploaded every time you change something in the package, even if this 
is a change specific to the debianisation process, and no new upstream 
version has been released. OTOH, having a debian_revision (i.e. a non-native 
package), when you change something to the debianisation process and create a 
new package with an increased debian revision number, you only need to upload 
the diff.gz to the Debian archive.

[1] http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version

pub 4096R/0E4BD0AB 2003-03-18 <people.fccf.net/danchev/key pgp.mit.edu>
fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB 

Reply to: