Re: Policy amendment to permit multi-line fields in debian/control
Hi,
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
DDPO.
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).
regards,
guillem
Reply to: