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

Re: Bug#203145: (uploaders in control) Note: not in .deb



On Thu, 19 Feb 2004 15:44:19 +0100, Jeroen van Wolffelaar <jeroen@wolffelaar.nl> said: 

> On Thu, Feb 19, 2004 at 03:18:55PM +0100, Bill Allombert wrote:
>> On Thu, Feb 19, 2004 at 02:44:15PM +0100, Jeroen van Wolffelaar
>> wrote:
>> > Please note that current packaging scripts do not propagate the
>> > Uploaders: field into .deb's. So either policy should not require
>> > that (or evenforbid it), or the packaging scripts should be
>> > changed to _do_ propagate this information (needing a rebuild of
>> > _all_ debs of packages that have comaintainers, but as a policy
>> > version bump requires such a rebuild, this is no issue).
>> >
>> > The .dsc has the Uploaders field propagated though.
>>
>> This is a standard dpkg behaviour. For each field, dpkg know
>> whether the field need to appear in .dsc, .changes or
>> DEBIAN/control, as explained in Policy chapter 5

> Indeed, and it says it isn't propagated at all for unknown fields,

	No. It says "user defined fields" and unsupported fields are
 not propogated. Obviously, fields that are propogated are supported
 by the packaging tools. 

> while it apparantly IS propagated for .dsc files: the Uploader:
> field must be somewhere coded in dpkg for this to happen (or dpkg
> isn't policy compliant and propagates any unkown field from
> debian/control to .dsc, but I won't assume this).

	Policy is neither all encompassing, nor is it documentation
 for dpkg.

> Anyway, how this is happening exactly is not relevant, what the
> policy should be is relevant, and current dpkg behaviour is of minor
> but indeed some importance (as it has direct consequences for ease
> of implementation of policy, simply documenting current behaviour
> would be by far the easiest).

	Quite. And policy is not meant to exhaustively define all
 fields in control files. dpkg can add more fields, and support them,
 if it is needed. 

	If there is need (and that is the operative words), currently
 used fields can be documented in policy. I fail to see the need in
 this case, but I am willing to be educated.

	manoj
-- 
The state of some commercial Un*x is more unsecure than any Linux box
without a root password... Bernd Eckenfels
Manoj Srivastava   <srivasta@debian.org>  <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C



Reply to: