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

Re: Updated maint-guide contents, question on style, my thought

On Mon, Apr 18, 2011 at 10:22:16PM +0100, Justin B Rye wrote:
>   There are two types of packages.
>   * binary package: these are ordinary installable packages in .deb
>     format (or .udeb format, used by the Debian Installer);
>   * source package: this is the name given to the set of files used as
>     input to the Debian package-building process - usually a .tar.gz
>     file, a .diff.gz and a .dsc file, whose functions will be
>     explained later.
>   Footnote: this terminology follows the analogy of program sourcecode
> 	being compiled into a binary.  Never mind the fact that we're
> 	calling linux-source-2.6*.deb a binary package.

Instead, I created overview section in chronological order of packaging
> [...]
> >>   * upstream source version: the upstream source version is referred
> >>     to as the upstream version.
> > 
> > This is inherited.  I think we need to standarize to "upstream_version"
> > and "debian_revision" if possible.

Using them in example was confusing since "_" has special meaning.
I reorganized a lot around this issue.

> >> But this still isn't true - the "upstream_version" is the
> >> Policy-compliant version string used for the Debianised sources.  If
> >> the upstream author uses a version string beginning with a letter
> >> then the "upstream_version" will be a different string.
> > 
> > Since this is a convoluted problem, let me think a bit more before
> > acting on them.
> I've ended up with something that's getting much longer:
>   The version numbering of Debian packages is formed from up to three
>   elements (see policy 5.6.12):
>   * the epoch: this may occur as a number prefixed to the Debian
>     version string to deal with hiccups in the numbering scheme;
>   * the upstream_version component: this is the version number for the
>     source package, based on (usually identical to) the number used by
>     upstream for the source release.
>   * the debian_revision component: this is a secondary label used to
>     distinguish successive forms of the same upstream source release,
>     as packaged for Debian.
>   The complete Debian package version for a normal binary package is
>   built up as upstream_version-debian_revision (or
>   epoch:upstream_version-debian_revision if an epoch is needed).  For
>   "native" packages, with no separate upstream [see ...], only an
>   upstream_version is needed.

I still kept away for epoch since that is something which should never
be used unless you made some versioning errors.

The string with <replaceable> and name of such string needs to be dealt
separately.  I hope new "Workflow of the Debian package building"

> But is this really something that needs to be explained here anyway?
> Maybe it would fit better in 2.4.

That what I did as 2.1.


Reply to: