"Pending" already. Maybe this reply is better late than never, though
it's relevant to the earlier 'freeguide' bug log, particularly
regarding homogenized upstream dates. Sometimes "one" bug is really
several.
On Thu, 20 Mar 2008 08:22:44 +0100
Raphael Hertzog <[EMAIL PROTECTED]> 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.)
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?
> ...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. For my purposes the whole source
'.deb' is virtually taboo.
> > Would a partial fix that only affected '/usr/share/doc/*' be safe
> > from tricky side-effects?
>
> If the files are simply copied over, their timestamp is already
> preserved. And it's unlikely that we patch upstream documentation.
>
> So no, I'm not in favor at all to add any complexity to the
> timestamp-resetting rule.
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'?
Some notes on date advancement ("date creep"?) in Debian...
Here's some ad hoc coding to see how often repeat dates occur in
'/usr/share/doc', i.e. many doc files per package with the same date.
On my system's 2920 packages, five or more doc date dups occur in
about 1200 packages.
# Top 10:
# usage 'pick 7 6' prints fields $7 $6 (1 to 9 only)
% pick() { z="$*" ; while read x ; do set -- $x ; for f in $z ; do eval echo -n
\$$f"\ " ; done ; echo ; done ; }
% for t in `cd /usr/share/doc/ ; find -maxdepth 1 -type d | sed -e 's#^\./##'
-e '/\./d'` ; do find /usr/share/doc/$t -type f -printf "%C@ \n" | sort -g |
uniq -c | sort -rg | xargs echo $t | pick 2 1 3 | xargs printf "%4i %40s %s\n"
; done 2> /dev/null | sort -g > /tmp/dupdate.txt
# 1) # of repeat dates
# 2) package name
# 3) the repeated date itself, in seconds since 1970
% tail /tmp/dupdate.txt
199 libcommons-lang-java 1200704724.0000000000
262 gnome-dev-doc 1188363464.0000000000
271 kde 1205914766.0000000000
289 debian-guide 1073455729.0000000000
302 openssl 1203115202.0000000000
391 HOWTO 1197753227.0000000000
431 lg 1113243150.0000000000
553 lilypond 1205128585.0000000000
641 RFC 1203416145.0000000000
648 mplayer-doc 1205119451.0000000000
I guess some of these might be affected by the pending #366555? For
those that aren't...
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'.
In theory it's easy to apply the same method to existing packages, either
starting from the earliest and working forward, or from the latest and
working back. (Given access to older '.deb' files, or their metadata.)
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.)
HTH...
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
