[Pkg-kde-talk] KDE 3.4 package underway

[Adeodato Simó]

* Christopher Martin [Wed, 02 Mar 2005 14:36:21 -0500]:

> >   Also, I have to write a mail about the manpage generation in
> >   debian/rules, putting that in kde.mk, and how would that affect
> >   packages that ship non-generated *.1 files.

> OK.

  The issue is clear: if you put this snippets into kde.mk:
  
common-build-arch:: debian/stamp-man-pages
debian/stamp-man-pages:
# Generate man pages for the programs
        for f in debian/man/*.sgml; do \
                docbook-to-man $$f > debian/man/`basename $$f .sgml`.1; \
        done
        touch debian/stamp-man-pages

clean::
        rm -f debian/man/*.1
        rm -f debian/stamp-man-pages

  You will delete non-generated manpages that exist e.g. in base,
  graphics and multimedia, because they are shipped in debian/man too
  (bindings, otoh, has them in debian/local).

  So, something like this could do instead:

 common-build-arch:: debian/stamp-man-pages
 debian/stamp-man-pages:
 # Generate man pages for the programs
-       for f in debian/man/*.sgml; do \
-                docbook-to-man $$f > debian/man/`basename $$f .sgml`.1; \
+       mkdir debian/man/out
+       for f in $$(find debian/man -name '*.sgml'); do \
+                docbook-to-man $$f > debian/man/out/`basename $$f .sgml`.1; \
         done
         touch debian/stamp-man-pages

 clean::
-        rm -f debian/man/*.1
+        rm -rf debian/man/out
         rm -f debian/stamp-man-pages

  And one changes {arts,kdelibs}/debian/*.manpages to use debian/man/out
  as path instead of debian/man alone. (The find instead of the glob is
  to prevent the loop from running in packages that lack .sgml sources.
  A 'test -f' could have been used instead.)

> > > sharutils I removed until we figured out a uu patch method,

> >   If you mean, 'until there is a uu-encoded patch needing it', I'd
> >   prefer to have it permanently, rather than add it when needed. I
> >   believe that the second method will end up in a FTBFS sooner or later
> >   (because it is easy to forget to add the B-D).

> That's reasonable. We (unless I'm missing something obvious...) just need to 
> figure out how to make CDBS work nicely with uuencoded patches. If the 
> built-in patch system can't do it, we'll have to handle it ourselves in 
> kde.mk.

  Should be fairly straightforward: a rule on which apply-patches
  depends that just uu-decodes the patches. OTOH...

> >   I intend to write a mail commenting how we manage branch pulls.

  The reason for uu-encoding branch patches is that we use diff -a
  because sometimes there are updates to binary files, e.g. .png images.
  This works, but having .uu patches is not so nice, for a number of
  reasons.

  I was thinking if we couldn't just make branch pulls with diff -Nru
  only, so that we don't need to .uu encode them, and them grep the diff
  for ^Binary and do something with those files. Opinions?

  Such "do something" could be, either do a diff -a for them, and
  uu-encode only that patch, or what Daniel does: put them in a tar,
  uuencode it, and ship that. In his clean target, he just removes the
  files, which afaik would make dpkg-source complain a little about
  "removed files" but nothing else.

  Also, I'd like that we timestamp branch diffs, e.g.
  01_kdelibs_branch_2005-02-27.diff. This was more useful when they were
  uuencoded, but I also like the approach even if they aren't. Is that
  ok?

> OK. Mind if I remove the debian/stamp-cvs-make stuff then?

  Uhm, yes, in the sense than in cdbs one usually keeps things even if
  he doesn't use them. More importantly, Daniel may want to use that
  snippets, and I wanted that the kde.mk in svn could be used by all...
  They are properly protected with an env var check, so I can't see big
  trouble with it.

  Cheers,

-- 
Adeodato Simó
    EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621
 
The surest way to corrupt a youth is to instruct him to hold in higher
esteem those who think alike than those who think differently.
                -- F. Nietzsche