dchanges problems/inconsistencies
I've just started thinking about my own script to produce dchanges
files, and I've come across a few inconsistencies/problems/misfeatures
in the dchanges format:
* There is some confusion about the Priority dchanges field. The
values listed in dchanges(5) are appropriate to the question `how
important is it that I should upgrade, if I have the old version ?'.
However, dchanges(5) conflates the field with the package's
installation priority shown in dselect, which answers the question
`how important is it that I should select and install this package at
all ?'.
Perhaps the upgrade priority (the former of the two) should be
renamed, but I don't have a good name for it.
* Many fields can be applied only to the whole upload, whereas for
many packages several binary packages are generated from the same
source code with different characteristics. Some of these
characteristics have been distinguished, but not all of them. I'd
like to see the ability to specify separate Architecture, Version and
Distribution for different files.
This is related to the syntax for the `Files' field, which is IMO
rather inflexible and inextensible.
Perhaps a simple way to deal with it would be to allow Architecture,
Version and Distribution (and perhaps other fields) to contain lists
which have the same length as and are in the same order as the files
listed, so that each file had a corresponding Version and
Distribution. Also, then the distribution section and priority could
be made separate fields, if this is thought appropriate.
Alternatively you could so something lilo.conf, where each file has
its own copy of many of the fields (Version, Distribution, MD5sum,
whatever) and a new file is introduced by a special field (eg
`File').
* How do I specify that a file is not a normal .deb file for placement
in the distribution, but needs maintainer attention ? Is there a way
of suggesting a location ?
Ian.
Reply to: