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.

On Tue, 5 Mar 1996, Richard Kettlewell wrote:

> Sorry to repeat myself but I don't recall seeing a clear explanation
> of why it's actually necessary for dchanges to extract a revision
> number - did I miss it?  It still seems odd that dpkg can manage
> without but dchanges can't...

Following is the response I posted to your first question.  I thought
I had answered the question.  What am I missing?

As far as dpkg being able to manage without, I'm not aware of dpkg
having a need to do anything with files having names which variously
end in .tar.gz, .diff.dg, perhaps .txt, maybe (and maybe not) .deb,
and perhaps others (or perhaps not).

--------------------------- CUT ----------------------------

On Sat, 2 Mar 1996, Richard Kettlewell wrote:

> While it may be easier to parse if there's always a revision field,
> I'd be interested to know why it's ever necessary to extract the
> revision field.  If it isn't ever necessary then it's obviously silly
> to require one to exist just to make coding easier!

Leaving the philosophical arguments aside for now, let me ask about
parsing of package file names without a revision field.  Take these:

    pkg-1.2.deb
    pkg-1.2.i386.deb
    pkg-1.2.386i.deb
    pkg-1.2.i.deb
    pkg-1.2.all.deb
    pkg-1.2.3.deb
    pkg-1.2.3.i386.deb
    pkg-1.2.3.tar.gz
    pkg-1.2.tar.gz
    pkg-1.2.tar.3.deb
    pkg-1.2.tar.3.all.deb
    pkg-2.deb.2.tar.3.diff.gz

OK, these are pretty silly package filenames, but let's not argue
about how silly some maintainer's version numbering conventions
might be as long as the version numbers are legal.

Where does the version number end and the extension begin?

Given cast-in-stone definitions regarding what extensions are
allowed, that can be determined.  However, that means that any
changes in those cast-in-stone definitions, the dchanges package
needs to be upgraded to track them -- and that's an unnecessary
housekeeping problem involving multiple maintainers.

If the form of the package filenames is simple and regular,
so that it can be parsed into fields, dchanges only needs to
be upgraded when the form of the package filenames changes.

> dpkg seems to manage without doing so, AIUI.

Does dpkg need to parse package filenames?