[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#46265: ftp.debian.org: misspelling in section: field for aleph-dev causes apt-get to fail update



On 30 Sep 1999, James Troup wrote:

> Fixed on master, will be corrected in tomorrow's dinstall run; maxima
> mea culpa for cut'n'wasting from the packages' priority field.  But,
> really, Jason, that sucks.  Mucho disrespect.  Dieing because it
> doesn't recognise the priority?  I mean, eww.

I've fixed this specific problem and made a parse error on the priority
field non-fatal (as it really should be) but I'm -not- going to make it
more robust against other kinds of simple errors. Unrolling in the middle
of a parse action is just too error prone and complicated to be worth
doing. 

Consider that this particular problem has been in the code for nearly two
years and we only triggered it once? The ROI just isn't there to warrent
the complication. 

The basic list of simple things that can go wrong is something along these
lines:
  1) An integer field does not have an integer
  2) A status field is not properly formed [this is very strict, requires 
     specific words in specific places]
  3) A depends-type field is not properly formed
  4) A boolean type field (ie Essential: yes) has a unknown boolean value
  5) A missing critical field such as Package: or Version:
  6) An improperly formed record in general

The only parsed field that can stand being invalid is the section field,
and now the priority field defaults to 'extra' if it isn't parsed.  The
reason the priority field was like that was simply because the rest of the
code is.

Now, a few fields could be made optional - but their absence would result
in degraded [to say the least] functionality, they are Size,
Installed-Size, Suggests, and Recommends.

This analness was built in primarly for parsing the status file where it
is critical that a misparse abort everything; least something awefull
happens. But on a Package file this isn't quite as nessecary. What I
wouldn't mind seeing is having a bad record just through out that one
record, but detecting a bad record before any changes have been made is
very expensive and undoing the parsing action mid-way is very complicated.

Jason


Reply to: