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



Carl V Streeter <streeter@cae.wisc.edu>

> If you want the package name, you can ask dpkg.  When all is said and
> done, THAT is the package name, not whatever the fist letters in the 
> filename up to a dash, or whatever method you wanted to use.

That's not workable, of course, if no .deb file is involved.
The great majority of uploads do involve .deb files, of course.
I was trying not to exclude the occasional special case which does
not include a .deb file.

There's some confusion, I think, about the term "package name"
in this discussion.  This confusion arises out of the fact that
there are source "packages" and binary "packages", and both of
these have a "name" attribute which is used to refer to them.

Given the three files:

   foo-1.2.3.4-5.tar.gz
   bar-1.2.3.4-5.i386.deb
   baz-1.2.3.4-5.i386.deb

Common parlance would refer to them as the "foo package", the "bar
package", and the "baz backage".  Occasionally, if the speaker or
writer wanted to be more precise than is normal, or if he wanted
to highlight the (type? class? category?) of package being discussed,
he might say "the foo source package" instead of "the foo package".

Now, presuming that the bar and baz binary packages are produced by
the foo source package, they'd hopefully have a "SOURCE: foo"
field in their control files.

It seems only reasonable to me that our package file naming standards
would specify a format that, given the filename "foo-1.2.3.4-5.tar.gz",
would allow it to be recognized as a source package named foo.  For the
life of me, I can't understand why people are arguing so energetically
against this.

> Given (nearly) infinite flexibily in nameing packages and version numbers,
> *both* of which may have dashes, parsing this information from filename
> only becomes an exercise in futility.

In the discussion regarding parsing of package file names which
took place either here or in debian-devel a couple of months back,
this was dealt with ad nauseum.  Dashes in the package name do not
cause a problem.  The rare case of an upstream version number with
a dash in it can be dealt with by requiring such (rare) dashes to be
transliterated to underscores.

> Now, consider this:
> I make a packages callex modules-1.xxx-1.deb.  In upload, this gets corrupted.
> I re-upload this as odules-1.xxx-1.deb, or new-modules, or whatever.
> 
> An automated script that parses the name from the filename would trash the 
> archive very severely very quickly.

The new (as net unreleased) dchanges supports use of pgp(1) to
sign changes files.  The man page which has been posted here
explains that.  The pgp-signed changes file includes the
filename, size, and md5sum information for all uploaded files.
The distribution maintenance scripts should not, of course,
process the uploaded material unless everything checks out.
Persumably, those scripts would send an email to the umloading
maintainer to let him know that there's a problem with the
material which he uploaded.

> If that's the case, why should other tools rely on methods which 
> don't generalize to the general case?

That needn't be the case.  See above.