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



On Sun, 10 Mar 1996, Nikhil Nair wrote:

> [...] here's something I 
> wrote in private email to Bill Mitchell a couple of days ago:
> 
> > It seems to me that
> > there should be a half-way house between the two camps ... here's a
> > suggestion: revisions are not compulsory for Debian-only packages, but 
> > *are* compulsory for others;

I may not have responded to this point in email.  I'm afraid that
I don't see what this accomplishes.

There's another question inside of this point -- exactly what is a
"debian-only" package, anyhow?  I seem to recall that at least one
package being produced for wide consumption originates and is
maintained by its "upstream" author on a debian system.  Is that
a "debian-only" package?  The debian dpkg package has (or at least
did at one time have) a non-debian counterpart named something like
nondebbin-dpkg.  Does this make dpkg something which is more general
than a debian-only package, and which has a debian-specific incarnation?

I don't have answers to those questions, and don't think that the
answers are terribly important in this context.  My contention that
the -rev part of package filenames should be compulsory has nothing
to do with the character of the package being named, and has nothing
to do with the meaning of the "rev" part after the '-'.  Rather, it's
based on the belief that, given a filename which contains several
meaningful components (e.g., name, version, extension, architecture,
debian_revision), it's useful to have that filename constructed
so that meaningful components which it contains can be pulled out
for examination fairly easily.

>                                 rather than *suggesting* that there be no 
> > hyphens in the upstream version, this would be *required*; finally, the 
> > revision field may not contain `.'.  This may be a bit complicated, but I 
> > think it's just about sufficient to make it possible to consistently 
> > parse filenames, without offending anyone ... or is that too much to ask for?

I've been having another offline discussion, in which the question
of "--" delimiters in package filenames was revisited.  When this
question was raised a few months back, I was against that.  I
contended that our package file naming conventions weren't sufficiently
broken to require such a fix.  Some simple rules for package file
naming grew out of that discussion.  Those rules never got picked up
into the packaging guidelines, and now there's all this opposition to
the -rev part which needs to be present for those rules to work to
produce a parseable filename.

Perhaps the discussion about "--" delimitors should be reopened.  The
original proposal was, I think, for a "--" delimiter between name and
version.  If this question is opened up again, I'd suggest that another
"--" delimiter be required between version and revision if the revision
part is present (and I still believe that it should be _required_).
Perhaps, if we're going to consider introducing a "--" delimiter,
we should go all the way with it and use it between all mandated
package filename fields.  Something like:

    name--version--revision--arch--ext
or
    name--version[--revision]--arch--ext
or
    name--version[--revision][--arch]--ext
    (but then, that introduces an ambiguity, doesn't it?
     If only one of revision or arch is present, is it revision or arch?)

Of course, any upstream package which appeared with a "--" in its
name or version would break this.  There'd need to be a rule about
how to handle this (unlikely but not inconceivable) situation.
I hesitate to suggest a transiteration to "__", since there's
presently opposition to transliteration of '-' to '_' for '-'
chars seen in upstream version numbers.