Re: dchanges problems/inconsistencies
Andy Guy writes ("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).
I don't think my version will suit everyone, because it appears that
different people have different ways of working :-)
...
> >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).
Well, I was thinking that that field was often useful for the humans
reading the package announcements - it tells them how much they need
to go out of their way to install the package sooner rather than
later.
> >* 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.
I'm afraid it does, I think. For example, my current dpkg source tree
produces both ELF and a.out packages, and I always distribute both.
> (Section/proirity overrides have been added in version 3.3 so you
> don't have to specify them in the .deb file).
Right (though if the maintainer is going to have to keep track of them
anyway putting them in the .deb file is probably useful).
...
[ Changed format for specifying details of multiple files ]
> 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.
Whatever you like - just document it :-).
> >* 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.)
Err, sf= is a dchanges option, isn't it ? I was wanting to know what
the syntax is in the changes file, because I'm trying to replace
dchanges ...
Thanks,
Ian.
Reply to: