[Debichem-devel] [Debichem-commits] r512 - in /wnpp/gabedit/debian: gabedit.1 gabedit.1.xml rules

[LI Daobing]

On 6/14/07, Daniel Leidert <daniel.leidert.spam at gmx.net> wrote:
> Am Donnerstag, den 14.06.2007, 07:10 +0800 schrieb LI Daobing:
>
> > suggestion on gabedit.1
> >
> > 1. if you choose to ship gabedit.1 in debian directory, you should not
> > regenerate it in build process, you can keep the generatrion rules in
> > debian/rules
>
> It should not be regenerated during "normal" operation, like package
> building. The chain only "regenerates" the manpage, if (a)
> debian/gabedit.1 has been removed (that's the reason, why I will refuse
> your second suggestion to avoid rebuilding the manpage every time) or
> (b) if the timestamp of the XML source file is newer than the one of the
> generated manpage.
>
> But how should this happen? The SVN will always contain the manpage. If
> changes to the source are done, running `fakeroot debian/rules
> debian/gabedit.1' automatically updates the manpage. Try to run it again
> and make will tell you, it's already up-to-date, so no further action is
> taken. And this should also be the case during a build run. The
> build-target checks for the existence of debian/gabedit.1.
> debian/gabedit.1 itself (as target) checks the timestamp of
> debian/gabedit.1.xml. Now it should detect, that it's own timestamp is
> newer than the one of the source and nothing happens. The manpage is not
> regenerated. But the whole depenncy chain makes ure, that (a) the
> manpage exists and (b) it's not older than it's source (so it's always
> up-to-date).
>
> Compared to the possibility, that I may forget to update the manpage
> manually (and upload them to SVN) after doing a change to the manpage
> source, the advantages are still on the side of the current solution.
>
> We use this way for shipping the manpages with their XML sources (with
> upstream) for e.g. gnome-chemistry-utils (docs/man/) and
> bluefish-unstable (man/) if you want to take a look.
>
> > but not let "build" depend on it.
>
> This is only a dependency chain to make sure, the manpage exists and is
> up-to-date.
>
> > 2. or you can choose not to ship gabedit.1, then generate it when call
> > "build", but you also need remove it when call "clean".
>
> See above. That's IMHO further a waste of time. There is no need to do
> this.
>
>
> My build logs do not show any unwanted regeneration of the manpage
> during an svn-buildpackage/pdebuild build. Does it happen for you? If
> yes, would you be so kind to send me the output of
>
> fakeroot debian/rules -d $target_that_regenerates_the_manpage
>
> then? The -d option adds debugging output, that gives more information
> about targets and dependencies.
>
consider we use "apt-get source gabedit" to get a copy of gabeit with
debian issues

in this case, whether gabedit.1's timestamp is newer than gabedit.xml
is unstable, so sometimes it will re-generate manpage and sometimes
not.

what do you think under this case?

-- 
LI Daobing