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: Whether Revisions should be required

Raul Miller <rdm@tad.micro.umn.edu> said:

> If I'm on debian revision 5 of version 2.1.103 of some software, and
> version 3.0.5 comes is released, what should the debian revision be?
> Is it revision 6?  What this version addresses all of the fixes I'd
> done to 2.1.103, and I need to back out all of my diffs and come up
> with a different debian.rules file?  Is it revision 1?

What I do is to try to confine my changes to files named
debian.something.  When a new upstream revision is released, I
unpack it, copy all my debian.something files over from the
old version's debian directory (that is, the dir which is not
named "name-version(without_revision).orig", but rather is named
just "name-version(without_revision)"), make a survey of the
debian.* files to see what changes might be needed in them
for the new version, make a survey of the non-debian files in
the old version for any debian-specific changes which they might
contain (but I try to avoid introducing any), Reset debian.README
to one initial changes info entry numbered "-1", and go from there.

> If revision has no existence except to distinguish between different
> local revisions to the upstream software, what's the advantage in
> being about to parse it out from the upstream version number?

Its presence, plus not having '-' in the version field, makes it
possible to parse interesting items of information such as the
package name or the package file extension out of a package filename.

> The purpose of revisions, in my opinion, is to impose an order
> on different instances of a particular package.  With only the
> upstream version number we could only implement a partial order -- but
> since such packages are typically released sequentially (with fixes to
> problems found in earlier package instances), a complete order is
> implied.  Revision numbers are a simple mechanism to let us impose a
> complete order on instances of a particular package.

What he said :-).