dchanges, architecture component, parseable filenames

[ian@chiark.chu.cam.ac.uk (Ian Jackson)]

We seem to be having quite a bit of confusion about the requirements
for uploading, dchanges, &c.

I'm going to list some questions that I'm not sure of the answers to.
Please don't immediately launch into a discussion of these issues -
I'll describe a little further down what I think the requirements are
for making this decision.

1. Is use of dchanges mandatory now ?  If so, what are we to do when
   it refuses to accept our uploads ?

2. Is signing release announcements mandatory ?

3. Is uploading a .changes file as well as posting an announcement
   mandatory ?

4. Do package filenames need to contain an architecture component ?

5. Do package .deb files need to contain Section and Priority fields ?
   Release announcements / dchanges files ?

6. Do we need parseable filenames ?  If so, what should they look
   like ?

I think that these confusions should be resolved as follows:

1. Use of dchanges: fine if this is made mandatory, but we need to
have a specification of the output format that is separate from the
implementation.  That way we can write the files by hand if necessary,
or (as I'd like to do) develop tools to help or replace dchanges.
Carl is managing the FTP site, so he should work out a format in
private in consultation with anyone (eg Andy Guy, the dchanges
maintainer) he thinks he needs to consult and then decree it.  Andy
Guy needs to be given some time to implement any changes, and then
Carl can decree the use of the new format.

2. Use of PGP: fine, but a statement needs to be made by Carl as soon
as the policy is firm.

3. Uploading/posting changes/announcements: I'm inclining towards the
idea that it would be good for the package maintainer to submit both a
signed dchanges file by FTP and a signed release announcement in more
readable format by email to the announcement address.  This could
easily be done automatically.  Carl and/or Bruce need to decide on the
procedure; I hereby volunteer to write a program to convert the
dchanges format to a more human-readable announcement format, when I
can find a specification of the dchanges format :-).  Bruce and Carl
should decide whether this topic needs further discussion.  Carl seems
to favour uploading of at least some of the changes information.

4. Filename architecture component: I do not have an opinion on
whether this is necessary.  If we do have an arch component it should
be the value of the Architecture field in the .deb file.  Carl should
decide whether it is necessary and announce what the policy is.

5. Priority/Section information: someone (Carl?) needs to decide the
data flow structure for Priority and Section information.  Currently
the information in the overrides file on the FTP site is considered
canonical by the Packages file cronjob and thus by dselect, and any
information in .deb files is optional and purely advisory.  What
happens at the moment to this information if it appears in changes
files is unclear to me.

6. Parseable filenames: I think we're going to continue to get into
problems if we don't, unfortunately.  In particular, FTP installation
is made much easier if we do.  However, most of the options are
aesthetically unpleasing, and the issue is something of a hot topic.

Let me go into some more detail about this:

I think our key objective, if we change things so that our filenames
are parseable, should be to ensure that they (and anything else we
need to change) continue to be as intuitive and aesthetically pleasing
as possible.

This means that solutions such as requiring package filenames to
consist entirely out of nicely easily separable components (eg
hello--1.3-4--i386--deb, as one proposal went) are out, because they
are overkill.  A program parsing filenames will be able to strip the
extension (deb, tar.gz or diff.gz) and architecture off easily even if
they were delimited by the more conventional dots, so we should use
dots.

The only problem is finding the boundary between the package name and
the version number.  The reason this is a problem is because package
names may contain hyphens, upstream version numbers may contain
hyphens, packages may not have revision numbers, version numbers may
start with non-numeric characters and package names may contain digits
following hyphens.

Any of the following options will be sufficient to give us parseable
filenames, and I can't see any other reasonable and minimal ones:

a) Decree that package names may not contain hyphens.  This may be
impractical as many packages currently contain hyphens, and many
people seem to like it that way.

b) Decree that upstream version numbers must be massaged not to
contain hyphens and that every filename must have a Debian revision
component.  Some people have an aesthetic objection to this because it
would require even packages which don't have Debian revisions a Debian
revision number (this is mainly special-for-Debian packages like
dpkg).  Others object because it requires more changes to upstream
version numbers than are currently required.  Changes to the upstream
version numbers of bind, elisp-manual, elm, fvmw2, lynx and tclX would
be required, and revision numbers would have to be added to dchanges,
dpkg and magicfilter (ppp and rxvt have no revisions but this appears
to be in error).  This option results in composite version numbers
containing always exactly one hyphen, for example dpkg-1.0.5elf-0.deb.

c) Decree that package names may not contain digits immediately
following hyphens, and that version numbers must start with digits.
The only package which currently violates this requirement is
xserver-8514.  Changes to the version numbers of amd, bison, cnews and
perl-tk would be required, but I have to say that those version
numbers don't look particularly like they'd sort well anyway :-).
This solution has the disadvantage of being fairly obscure.

d) Use some kind of special notation, such as replacing the separating
hyphen with a pair of hyphens, an at sign, a comma, a colon, an equals
sign, an underscore or some such (eg dpkg:1.0.5elf.deb).  This has the
advantage of being straightforward but the disadvantage of being
plainly ugly.

e) Encode hyphens in package names and/or version numbers as some
other character; perhaps changing hyphens in package names to
underscores (which aren't legal in package names at the moment), eg
ncurses_term-1.9.8a-4 (where the package is ncurses-term, version
1.9.8a-4).  This has the disadvantage of being a little less than
obvious.

The main distinctions between the above four options (d,e with many
suboptions) appear to me to be aesthetic.  There's very little you can
say in the way of argument in favour of them - you just have a feeling
for which one(s) you (dis)like.

I'm therefore wondering if the best way to resolve this issue might
not be a vote.  A vote is usually a poor way of arriving at good
technical solutions to things, but better at deciding which of a pile
of aesthetically distinct alternatives is least objectionable.

If we're going to have a vote we need a list of options for d) and
should probably use STV.

The options for d I can think of so far are replacing the delimiter
with one of  _  =  :  @  ,  --

The most aesthetic option for (e) I can think of at the moment is
replacing hyphens with underscores in the package name; other people
may suggest more.

Ian.