On 4/22/06, A. Costa <[EMAIL PROTECTED]> wrote: ... > > 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'.
The bug probably shouldn't be closed. I would tag it wontfix, and post it on debian-devel for discussion. That dpkg-source doesn't preserve time stamps is a straight-forward bug. > > 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? Any conversion performed on a regular, automated basis doesn't warrant updating the time stamp. However, if a developer runs help2man once by hand to create a man page, I would update the time stamp. > > 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 ... > 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? Exactly. Time stamp information is meta-data, and a lot of mediums don't preserve meta-data. For example, when a document is attached to an email, typically the time stamps, permissions, et cetera are all lost. Likewise for the Debian diff. All the Debian packaging, including documentation, is packaged in the diff, and by default, debuild does not preserve the time stamp meta-data in the diff. I don't know why this is though, because diff does, by default, preserve the time stamp meta-data. Cheers, Shaun
