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

Re: Policy amendment to permit multi-line fields in debian/control


On Tue, 2006-04-11 at 17:04:17 -0700, Russ Allbery wrote:
> I have proposed a modification for Policy that will permit wrapping in the
> following fields in debian/control:
>     Depends Recommends Suggests Enhances Pre-Depends Conflicts
>     Provides Replaces Build-Depends Build-Depends-Indep
>     Build-Conflicts Build-Conflicts-Indep
> and recommend ("should") that all packaging tools support wrapping in:
>     Uploaders
> with a note that, in the future, support will be mandatory and packages
> will be allowed to wrap the Uploaders field.

> My belief is that this is the current behavior of the packaging tools and
> that this does nothing beyond bring Policy in line with the current
> implementation.  (Uploaders is left in a separate category because I
> believe this was already supported by the version of dpkg and dpkg-dev in
> sarge for all fields except Uploaders.)  However, I would greatly
> appreciate it if you would look over Bug #148194 against debian-policy and
> follow up in that bug with any concerns or problems that you have with
> this change.

I'm completely fine with this change (as can be seen from the bug
report ;). dpkg has supported multi-line fields for a long long time,
it has only been recently that it has started unwrapping the lines
when generating other control files from debian/control. This was done
mainly because of the policy and because few tools broke, namely the

The relevant changes by Frank Lichtenheld that introduced line
unwrapping in dpkg are:

dpkg (1.13.14) experimental; urgency=low

  * Strip any newlines from Uploaders field on dpkg-source -b.
    Closes: #254449

dpkg (1.13.12) experimental; urgency=low

  * Let dpkg-source -b check the build relation fields before
    putting them into the .dsc. As a side effect they also
    get normalized. Closes: #254449

So you may want to consider Upladers in the same way as the other
fields, be it a "must" or a "should" (personally I'd go for the
first one, but could understand the second option).


Reply to: