On Tue, 18 Apr 2006 07:40:59 -0600 "Shaun Jackman" <[EMAIL PROTECTED]> wrote:
> This hypothetical tool should belong to the debhelper tool suite. It > is most related to the dh_installdocs tool. At least, dh_installdocs > copies the documents into the package, and it could also possibly set > the time stamps. Where it gets the time stamp information from is > another matter. Alternatively, there is a tool dh_fixperms that goes > through the package fixing permission modes. A new utility, > dh_fixtimestamps, could operate in the same vein. > > I'm going to reassign this bug as a wishlist item to the debhelper > package. Thanks for making the call, but just as the little bug was a symptom of a bigger systemic bug, now the bigger bug closing is perhaps a symptom of the biggest bug yet; the BTS makes it very easy for overworked maintainers to forget what they're doing here, and maintainers are their own guardians. (And on the whole, they do a great job, considering human nature...) To elaborate, the maintainer of 'debhelper' sees that the wishlist remedy seems to contradict his vision of packaging simplicity and elegance; fair enough, but then he forgets that the origin of this bug was a symptom, not a proposed remedy -- that is, closing the wishlist bug neither solves the problem of useful date information being lost in '/usr/share/doc' nor addresses the symptom in 'freeguide'. Assuming that a wishlist was indeed a bad idea, then to make the best use of the BTS, the bug should be reclassified to wherever it best fits; or put aside until it makes more sense. For example, it might be reassigned back to 'freeguide' and tagged 'upstream' or 'wontfix'. > > Another thing to decide would be for cases where Debian takes one > > doc file and converts it to another format, should the converted > > file keep the original file's date? Note: if nothing has changed, > > the converted file, if needlessly reconverted on every new Debian > > version, should at least keep the date of the last differing > > conversion. > > Preferably, the installed document should have the same time stamp as > the document's source file. Preferably, but I'm thinking of cases where the automated conversion adds or subtracts enough data to make its revision noteworthy. Suppose a man2info converter deletes boilerplate paragraphs about "see the info page" since those are redundant in the info page itself. Would that be different enough to deserve a new date? > > > The Debian specific documentation is another matter. I should be > > > able to keep the time stamps of README.Debian, changelog.Debian > > > and copyright correct. I'll keep this in mind the next time I do a > > > maintenance release of FreeGuide. > > > > That'd be good too. Thanks for maintaining the package! > > I'm afraid fixing the time stamps of the Debian documentation is > actually *harder* than fixing the time stamps of the upstream > documentation. The Debian documentation is distributed in a patch > (.diff) file, which does not include any time stamp information -- or > any meta-data at all for that matter, such as file permissions! So, > every time one unpacks the source package, the time stamps of all the > Debian documentation take the time of the unpacking. I dunno, a patch, a doc, what's the difference? If the patch is later than the original doc, then the resulting patched doc should have the date of the patch. A patch is just an abbreviation for a whole new file; think of a patch as a revised edition and it becomes straightforward. Perhaps I've misunderstood what you're saying about Debian's patch system. Did you mean that all patches, old or new, are "born yesterday" on unpacking? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
