[Dctrl-tools-devel] Bug#525525: Bug#525525: Bug#525525: do not separate stanzas with empty lines when showing Description field only

[Stefano Zacchiroli]

On Mon, Aug 24, 2009 at 05:33:03PM +0300, Antti-Juhani Kaijanaho wrote:
> On Mon, Aug 24, 2009 at 03:56:45PM +0200, Stefano Zacchiroli wrote:
> > Mmmmmhhh, I surely understand your consistency argument, but I confess
> > I really don't see where the "feature" is.
> 
> A feature is something the developer intended, a bug is something
> the developer didn't intend.  A feature can certainly be a bad idea,
> making it a misfeature.

Sure, I didn't want to challenge the general principle. Maybe I
expressed wrongly the concept, but what I wanted to know was why back
then you considered that a feature. Eyeball friendliness you mentioned
is probably the reason.

> > Actually, you just made me wonder whether APT and friends would digest
> > stanzas not separated by empty lines (which technically are not
> > required by the mbox format whereas they are always there in
> > practice).
> The mbox format is not relevant here.  It's only superficially
> similar to the dctrl format.
> 
> My gold standard for input is Debian policy, plus what the tools
> handle.  The output should be that too, except for the hysterical
> reasons discussed above and earlier, it isn't.

I'm not sure whether dctrl is standardized anywhere.

I've just checked policy which contains (§5.1) something called
"control files", definition that applies to the various stanzas of
debian/control. That syntax prescribes an empty line.  However, what
you are grepping through are files handled by APT and dpkg which I
believe fall outside the scope of policy in that respect.

> Now, I wonder if we can just say "sorry, you lose" to any script
> currently depending on this misfeature?

As usual, it depends on how many people are relying on that. An
argument that I'd like to put forward is the following:

- the proposed change affect the output only when a single multiline
  field is selected; the current output in that case does not have
  blank lines as separated

- hence, people relying on that output are already detecting, as
  postmark of a new stanza, a non-indented ^Description (or its
  equivalent)

- assuming that the new behavior is to output an empty line in that
  case (assumption that needs to be validated), the detection of new
  stanza will not break

The only "breakage" would be that people relying on the old behavior
will get an extra empty line as part of their Descriptions. The
breakage (if any, given that current multiline fields would need to be
joined to be useful) looks like very minor to me.

Does this argument look convincing?

Thanks for your feedback.
Cheers.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...........| ..: |.... Je dis tu à tous ceux que j'aime
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/dctrl-tools-devel/attachments/20090824/1d8b138e/attachment.pgp>