Hi, On Fri, 28 Mar 2008, A. Costa wrote: > > To be clear: this bug #366555 is assigned to dpkg-dev and dpkg-dev > > doesn't control the timestamp of generated documentation. If you want > > the generated documentation to have a timestamp that matches the > > source, you should just write a tool that makes it easy to do so and > > hope that some maintainers will use it to fix timestamp of the > > generated documentation (but I doubt it, honestly and the maintainer > > of debhelper is very much a reference concerning what is a reasonable > > packaging helper tool). > > I like your idea, it'd be a workable kludge pending some eventual > systemic fix or '.deb' revision. It might work at install time, a user > tool, rather like 'apt-listchanges' or 'localepurge'. (See below for > details.)
I rather meant a build-time tool like: sync-timestamp <reference> <destination> Where <reference> is the original file (say in XML format) and the <destination> is either a file or a directory with multiple files. > But if 'dpkg-dev' isn't relevent, (IIRC Shaun Jackman reassigned it from > 'freeguide' to 'dpkg-dev'), then where to assign this other (correcting > upstream dates) bug? Nowhere. If the idea is to write a new tool, there's no pre-existing package where to reassign it. > > ...Up to now all files from the debian sub-directory are installed by the > > diff.gz and thus get a timestamp reset by dpkg-source. In the future, > > when we switch over to the new source format the files in the debian > > directory will be installed by a debian.tar.gz file and thus we will > > preserve timestamps. However upstream patched files will continue to > > have their timestamp reset at unpack time. > > So if I understand things correctly, the 'upstream' part of a package > is inviolate, never changing. At present there's no preservation of > patch timestamps, (always the latest patch/unpack time), and no > provision for correcting upstream metadata -- the current format > and tool chain are not designed for (you and JH argue) any such > proposed metadata functions. Yes. > The user changing doc dates after or during the install would be OK? > Assume the source '.deb' is untouched. Would install-time date changes > be any worse for a system than say, 'localepurge'? Well, I have no problem with the user changing timestamps of installed files if that's something desirable to the user. But I really don't see how you would expect this to work. > Idea about a 'Debian day 1' date for upstream packages like the above. > Earlier I suggested saving the dates the first time it's packaged. > Hess objected to polluting the source '.deb' with an added data > structure and handling code. On 2nd thought: no additional data > structure is needed. An older or installed package version already > contains the desired metadata. > > Supposing version numbers are whole numbers: > > 1) Day 1, version 1, relative to Debian or the users system, > installed package has upstream dates. No change from how > it's done now. > > 2) Version 2, relative to Debian. Before unpacking, go through > 'doc' dir, compare checksums to "version 1", if they match, > use the old dates. > > 3) Version 'n' compare to version 'n-1'. Ouch. What a lot of work for simple timestamps. And it has problems: a compressed documentation file will have a differing checksum even if the content does match as the gzip header includes some timestamp as well. So yo should compare uncompressed content. Many auto-generated documentation will also include some sort of timestamp in the generated page as well. > So, a util that runs on a package upgrade, before it's unpacked**. > Save prior version's doc date & checksums to temp file. After > unpacking, compare, then backdate unchanged doc files as needed. > > (**is there a "Debian Way" to run on upgrade before unpacking? I know > how to code the rest, assuming I've not forgotten some other necessary > difficulty.) Well, right now there's no such "hook" defined in dpkg. Thus this feature can probably only be developed as a dpkg patch. But I can tell you in advance, that any such wishlist bug against dpkg will be tagged wontfix as it's way too complicated for too little gain. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/
