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
