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: Guidelines docs on ftp.debian.org.



Richard Kettlewell <richard@elmail.co.uk> said:

> From: Miquel van Smoorenburg <miquels@Q.cistron.nl>
> >The guidelines do not mention the Package-Revision: field, but the
> >sample-files do. Help! :) [I think it would be good to restore the
> >usage of that field]
> 
> What do you want to use it for?

I just did a quick survey of the 354 debian binary packages currently
present on a system I have handy, and found the following:

 47/354 (13%) have revision information in the version field
 12/354 (~3%) have no revision information
  2/354 (~0%) have apparent versioning errors
293/354 (83%) still have a separate Package_revision field

(this was done quickly, and I may have miscounted a package or two,
 but it ought to be mostly correct)

Some of the 12 packages having no debian revision information look
doubtful as debian-specific packages.  These are:

    lilo-17
    dpkg-1.0.15
    lrzsz-0.12a
    minicom-1.71
    gnats-3.2
    gnats-user-3.2
    joe-2.8
    ucbmpeg-1r2
    ucbmplay-2.3_patchd
    octave-1.1.1
    watchdog-0.3
    gsfonts-2.6.1

The two apparent versioning errors I saw are:

   The mbr package is version "0 0"
   The itimer package is version "="

What I personally think ought to be done is the following:

1.  The 83% of the packages which still have a revision field
    do nothing.

2.  The 17% of the packages which lack the revision field put it back
    in.  Those which have revision information in the version field
    move it to the revision field.

3.  The packaging guidelines revert to requiring a separate package
    revision field for all packages, containing debian revision
    information.  If the package maintainer is of the opinion that
    the concept of debian revision information is not applicable
    to his package, he should arbitrarily place a "0" in the
    package revision field.

4.  All the people spending time on this issue should move on to
    something more productive.

However, that probably makes too much sense for us to do it.