That's a good point.  I was erring on the what if the description contains the delimeter, and shifting off 'the original fields', but there is no guarantee either way.  We've gone from parsing a line of fields delimited by whitespace to a line of fields delimited by whitespace and a special token where one of the fields now itself contains whitespace.

We can use a regex to capture the leading fields, which I believe are guaranteed by their whitespace delimiters, and then the rest is description.

Or we can be verbose and explicit about the whole parsing process for both rpm and dpkg, as you were suggesting yesterday, and break every field with linebreaks and clear start of/end of tokens for an entire package entry.

START
DESIRED: install
ERROR: ok
STATUS: installed
NAME: a-package
ENSURE: 2.0
DESCRIPTION: This is a summary of a-package.
 It also has a longer description which drones
 on and on and on
END

It does take all the ambiguity out and would let us write a little lexer class shared by both packagers.  Lexer would take an io of formatted dpkg/rpm output and return a hash of fields based on the field keys between START and END, while automatically ignoring any lines which don't begin /[A-Z_]+:/.

It will be slower.

Either way, I'll add more tests for edge cases.