The debian-private mailing list leak, part 1. Volunteers have complained about Blackmail. Lynchings. Character assassination. Defamation. Cyberbullying. Volunteers who gave many years of their lives are picked out at random for cruel social experiments. The former DPL's girlfriend Molly de Blanc is given volunteers to experiment on for her crazy talks. These volunteers never consented to be used like lab rats. We don't either. debian-private can no longer be a safe space for the cabal. Let these monsters have nowhere to hide. Volunteers are not disposable. We stand with the victims.
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: dchanges file for non-intel archs

On Sat, 2 Mar 1996, Richard Kettlewell wrote:

> Bill Mitchell writes:
> 
> >I'm hoping that this is in final form, or close to it, but it's
> >not yet cast in stone.  Constructive input would be welcome.
> >
> [...]
> >       For packages specific to the debian distribution or having no
> >       upstream main- tainer, the debian revision number might be
> >       arbitrarily set to 0 or 1.
> 
> Why not simply not have a revision number at all, as with current
> practice?

That's current practice with some packages, and not with others,
and only applies to a very small subset of the debian packages:
purely debian packages whose maintainers would opt for a version 
numbering style of <level1>-<level2> vs. <level1>-<level2>-<level3>.

Special cases are messy.  Unnecessary special cases are unnecessarily
messy.

There's little point in all package handling scripts which need to be 
concerned with parsing upstream version numbers out from debian revision 
numbers needing to support the special case of packages without any 
debian revision numbers at all unless there's good argument to be made
that the special case is necessary.

It's a small burden for package maintainers who provide packages
which don't have a more generic non-debian package behind them
providing a <level3> version number part which is arbitrarily fixed
at (say) 0 or 1 (e.g. pkg-1.5-1 vs. pkg-1.5), thus eliminating the
special case handling for that small subset of debian packages on
what is purely a version numbering style issue.

Even for purely debian packages, I think it makes sense to increment
the <level3> (debain revision) number when, for example, making a change
to the dependency line in the debian control file; but that's a
package admin issue which can be left to the package maintainer
without impacting the package handling scripts.  If the maintainer
chooses to increment the <level2> number instead of the <level3> number 
when he makes a change affecting just the debian control files in the 
package, it doesn't affect the processing done by the package handling 
scripts.  Those scripts will have a package name in the form:

    package_string - version_string - revision_string

to work with, where version_string is known to contain exactly one '-'
char vs. one where version_string might or might not contain a '-'
char, and the presence or absence of that '-' char in version_string
impacts parsing the naming components out of the package filenames.

How many packages are we talking about where this is an issue
(that is,  where the maintainers of purely debian packages would
prefer to version number their packages <level1>-<level2> instead
of <level1>-<level2>-<level3>)?  two? three? five? more?
Out of how many debian packages? hundreds?