Re: dchanges, architecture component, parseable filenames

[Andy Guy <awpguy@acs.ucalgary.ca>]

I've re-ordered things so Ian's questions come with his answers:

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

Some of the problem (with dchanges) is that I havn't been getting
debian-devel for most of April and so wasn't available to answer
peoples questions (and find out what problems they were having so I
could fix them).

>1. Is use of dchanges mandatory now ?  If so, what are we to do when
>   it refuses to accept our uploads ?
>
>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.

The current format is described in dchanges(5).  Before fixing it in
stone we need to see how it fits into the overall picture - it is an
interface between developers and the ftp site (and therefore Carl).  I
have tried to make it so that an automated system can be developed
using it.

The current version of dchanges is a shell script - I am planning (and
was going to announce this shortly) to move to python for the next
major version.  I tried perl for my latest version of dpkg-ftp and
didn't like it.  Currently the python distribution is large (emacs
like) as it includes tkinter and lots of docs/developement components
- I have talked to Kees about this and he said that he will be
releasing a new version that is chopped up into its various pieces.
This new version would mean that the basic interpreter and modules
would be smaller than perl.  I am also happy to help implement the
ftpsite side of things as well (again in python).  So the question is
are people happy using python? (Its nice really).

If people don't like python I will keep it as a shell script (or maybe
move to perl but probably not).

><removed question 2>

>
>3. Is uploading a .changes file as well as posting an announcement
>   mandatory ?
>
>< removed Ian's answer>

I like the idea of mailing the .changes file in after the files have
been uploaded.  This gives a return mail address to send problems to
and can also be used to prod the automated systems into action.  After
the files have been installed an announcement can then be sent to the
required mailing lists - if the original one is mailed in simply
forwarded it perhaps and allow extra comment before the actual changes
fields.

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

I feel this is a good idea, then all packages can be uploaded to same
directory and the problem of uploading mutliple architectures in one
changes file can be easily dealt with.  

(Also perhaps create binary-all and put "all" arch packages there and
make symbolic links from the binary-<arch> directorys when the
depends field has been satsified.)

>5. Do package .deb files need to contain Section and Priority fields ?
>   Release announcements / dchanges files ?
>
>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.

I got confused by this and got things wrong - and have now spread my
confusion - sorry folks.  Current version of dchanges assumes sections
are set in the .deb file or the section is misc (or someother default
set by the user).  I think this isn't a bad idea anyway.  IMO an
automated system shouldn't allow people to place packages in base/high
proirity/mark essential without checking with Carl in some way (the
programs that is).

>6. Do we need parseable filenames ?  If so, what should they look
>   like ?
>
>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.

I should note here I originally took over dchanges from Bill because I
felt we didn't need parseable filenames but somehow became an advocate
for them.  I don't see the need for them (both dpkg-ftp and dftp no
longer parse them).  The only problem is source files - but a better
solution imho is a source package scheme so the contents of the files
identify the source package/version.

[Side note to Ian: I notice that you are developing a new file format
based on ar format archive, where the first file name identifies the
type, could you add a last file md5sum and contains the md5sum
of all of the rest, this would allow intergrity checks to be done by
checking that:
	ar x <archive> md5sum
matches:
	ar p <archive> `ar t <archive> | grep -v md5sum` | md5sum

easy to add:
	ar p <archive> | md5sum > md5sum
	ar a <archive> md5sum

This would be good for cd makers and people ftping (which means
everyone I think!)
]

Andy.