Bug#666726: debian-policy: Clarify if empty control fields are ollowed or not
On Sat, Nov 22, 2014 at 08:15:03AM -0200, Henrique de Moraes Holschuh wrote:
> On Sat, 22 Nov 2014, Charles Plessy wrote:
> > Le Fri, Nov 21, 2014 at 10:56:15AM +0100, Bill Allombert a écrit :
> > > What about automatically generated control files and substvar ?
> > > e.g.
> > > Depends: ${misc:Depends}
> > > where ${misc:Depends} resolve to the empty string ?
> > >
> > > Does dpkg-gencontrol take care of that ? In that case we should not lead people
> > > to believe that the above is incorrect.
> >
> > a quick check where I added "Recommends: ${misc:Recommends}" and "Suggests:" to
> > the source control file of the "hello" package suggests that empty fields
> > are removed by default.
>
> Empty fields in debian/control must be valid in *source* packages. It is a
> widely used feature of the dpkg-dev suite, and it has been around for a very
> very long time AFAIK.
>
> I don't think they are allowed in binary packages (deb/udeb), though.
>
> I suggest we add explicit documentation in policy to reflect reality: the
> package build process must accept empty fields in the debian/control file of
> the source package being built, and must remove all empty fields from the
> control file of the binary packages the package build process generates.
In that spirit I offer the following patch.
By the way, is the statement
' A paragraph must not contain more than one instance of a
particular field name.
'
true for all fields in debian/control ?
Cheers,
--
Bill. <ballombe@debian.org>
Imagine a large red swirl here.
diff --git a/policy.sgml b/policy.sgml
index 6eac491..66de529 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -2556,13 +2556,15 @@ endif
<example compact="compact">
Package: libc6
</example>
the field name is <tt>Package</tt> and the field value
<tt>libc6</tt>.
</p>
-
+ <p> Empty fields value are only permitted in source package control files
+ (<file>debian/control</file>). Such fields are ignored.
+ </p>
<p>
A paragraph must not contain more than one instance of a
particular field name.
</p>
<p>
Reply to: