Re: dchanges problems/inconsistencies
Note: there is a new version (3.3) of dchanges siting in Incoming.
Ian Jackson writes:
>
>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:
If you are going to do this why not make this the official one?
A couple of people have come out of the wood work and said they don't
like having to use python. (It is currently a shell script and I'll
probably keep it that way for now).
>* 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.
In my working notes for an automated system I have dropped it as being
confusing and unnecessary. Nothing planned will use it and if it
upgrade is important a note should be added (I suppose in the future
if some comes up with a system that processes the changes file mailing
list and upgrades there sytem there might be a use).
>* 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.
Version is the source version. Architecture should be Architectures:
and is really for changing maintainers. These fields can be dervived
from the .deb files and are only really needed when changing
maintainers. You can get version information out of the .deb files
(any system should check that the information matches anyway).
dchanges already handles the case were one source file produces
several binary packages that go into different sections/priorities and
have different versions. They must use a correct Source: field (but
this should be required anyway) - someone really should updated
deb-control(5) man page. It dosn't handle the case for different
distibutions I didn't see the need - but perhaps this needs to be
changed.
(Section/proirity overrides have been added in version 3.3 so you
don't have to specify them in the .deb file).
>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.
I really dislike this (the way it is done in the Packages file format)
it makes it difficult to check by eye - ie dosn't associate related
information.
>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').
I would certainly prefer this. How about something like:
File: <filename>
Size:
MD5sum:
Type: <binary> or <source> or <other>
Section:
Priority:
Distribution:
Destintation: <destination for the file in the debian/ tree>
.... anything else you can think of.
Size and md5sum are required.
Section and Proirity fields also can be specified to give 'default'
values.
>* 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 ?
Use sf= override to add special files (basically to be handled
directly by the distribution maintainer.) (This is documented.)
Andy.
Reply to: