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 Wed, 6 Mar 1996, Ian Jackson wrote:

> It seems to me that Bill thinks that if we make revisions mandatory he
> will be able to parse the package name, version and revision out of
> the filename(s), and that this is why he wants to make it mandatory.
> Apparently he thinks that if revisions are mandatory then every
> version number will contain exactly one hyphen.
> 

Yes, separating the upstream_version_number_part (formerly
known as the version number) from the debian_revision_part
(formerly known as the debian revision number).

> However,
> 
> (a) dchanges does not need to parse the package name, version and
> revision out of the filename(s) - it can look inside the .deb file
> which it is be supplied with to determine this information.

True, if a .deb file is supplied.  dchanges doesn't currently work this
way, but I guess I could rewrite it (yet again) to work that way.

If a .deb file is not supplied (the kermit package, for example,
involves no .deb file upload to the distribution maintenance site),
dchanges would having a problem.  With files named, for example:

    w3-el-2.2.25.tar.gz
    w3-el-2.2.25.-4.tar.gz
    wu-ftpd-2.4.tar.gz
    wu-ftpd-2.4-16.tar.gz
    kermit-190.txt
    kermit-190-7.txt
    aout-binutils-2.5.2.foo
    aout-binutils-2.5.2-7.foo
    elv-vi-1.8pl4.bar
    elv-vi-1.8pl4-12345.bar
    tcl-74-dev-7.4p3.baz
    tcl-74-dev-7.4p3-2.baz
    tcl-74-dev-7.4p3-2.deb
    tcl-74-dev-7.4p3.i386.deb
    tcl-74-dev-7.4p3-2.foo.deb

Might be difficult (impossible?) to parse for package name in all
cases.

(based on real-life examples lifted from the package file, and chosen
 without any intention of spotlighting any of the packages named here)

The only gotcha which I see with binary package files  is for packages
named something like

    foo-1.2.3.4.i386.deb
    foo-1.2.3-4.g246.deb
    foo-1.2-3.4.m68k.deb
    foo-1-2.3.4.alpha.deb
    foo-1.2.3.4.sparc.deb
    foo-1.2-3.4.beta.deb
    foo-1.2.3-4.a45b.deb
    foo-1.2.3.4.ppc.deb
    foo-1.2.3.4.gamma.deb
    foo-1-2.3.4.abc.deb
    foo-1.2.3.4.hp.deb

If only one of these .deb files is supplied, there's no Architecture
field in it, I guess the presumption could be made that packages
without architecture fields are i386 packages without an architecture
field in the filename either, and an "i386" architecture field inserted.

(Regarding the foo-1.2.3.4.i386.deb file, was the "i386" portion
 of the filename an architecture field or part of the version number?
 It's a judgement call (a guess, that is).)

It's just soooooooo much simpler if the filename is parseable.

And, as so many others have pointed out, regularity is a virtue.

> and
> 
> (b) it wouldn't work anyway, because both package names and upstream
> version numbers may contain hyphens.

Hyphens in the package name are not a problem if the rules are followed.  
Hyphens in the upstream version number are required to be transliterated
by the source package maintainer to some other character (underline 
suggested).

I do see one single package in the development distribution which
violates the rule of having no hyphens in the version number:

    elisp-manual-19-2.4-1

This should be parsed by the current dchanges with the name as
elisp-manual-19, the version as 2.4, and the revision as 1.
According to the packages file, however, the name is elisp-manual,
the version is 19-2.4, and the revision is 1.

mitchell@mdd.comm.mot.com (Bill Mitchell)