Re: New packaging manual draft
Manoj Srivastava wrote:
> Joey> the line. Horizontal whitespace (spaces and tabs) may occur before or
> Joey> after the value and is ignored there; it is conventional to put a
> Joey> single space after the colon.
>
> Joey> Is the space before the colon truely optional? I expect
> Joey> there's some broken code out there if so. RFC 822 does allow
> Joey> it. I
>
> Umm, what space before the colon? We say it has a neme, a
> colon (see, no space), and a value. The value may have spaces aroud it
> (that would be after the colon). What am I missing?
Sorry, I was referring to the space after the colon.
> Joey> think you should point to that RFC in that section BTW, even
> Joey> though control file format varies from it in several ways.
>
> Color me puzzled. If we are so different from teh RFC, why
> should we mention it?
We're not really that different. The rfc allows any line to be wrapped,
we do not.
> Joey> The list of distributions values and their descriptions seem
> Joey> out of place. In several places it seems to be talking to the
> Joey> end user.
>
> I have updated the list to use the same syntax as the policy
> manual, and put it into a footnote, so this is now
> informational. This paves the way for totally new formats of
> distributions and sections with the poackage pool ;-)
Good.
> Joey> While section 5.4 is of course very useful and important information, I
> Joey> question the value of including it in policy.
>
> It specifies under what circumstances the scripts are called,
> and what the maitnainer script writers are expected to
> handle. Inclusion here makes it a standard public API, and would
> require a public peer review to change.
>
>
> Joey> If someone decides to go make dpkg even more robust, and deal
> Joey> with problems after that point and manage to back off after
> Joey> that point, it would be technically in violation of policy. I
> Joey> see no reason to put such a damper on future progress.
>
> I do not think that this is meant to be a fault of the
> packaging system. There has to be a point of no return -- and this
> documents where that point is. I would much rather have a well known
> point of no return -- and perhaps code accordingly, than not.
But my point is that this is an implementation detail. I can envision
systems that have no point of return, and can always be rolled back
(think journaling filesystems).
--
see shy jo
Reply to: