[Debian GNUstep maintainers] First version of split gnustep-dl2 at mentors

[Yavor Doganov]

В Tue, 02 Mar 2010 09:48:00 +0100, Federico Giménez Nieto написа:
> 2010/3/1 Yavor Doganov <yavor at gnu.org>:
>> I see no doc-base file here?

> It should be there, i created it as gnustep-dl2.doc-base, with HTML and
> PDF formats...

Sorry, my mistake.

>> * GDL2: (GDL2-Intro).   GNUstep Database Library Introduction.

s/GDL2-Intro/GDL2Intro/ here; sorry for misleading you.

>> It is important to have a @dircategory besides @direntry

> Added. I had a quick look at the Free Software Directory and didn't find
> any category related to GNUstep, nor Objective-C.

That's right; there is no such category, that's why I suggested
"Software libraries" which seems to suit best.

> In this case it is intentional, shouldn't be the documentation placed at
> /usr/share/doc/<package> according to the FHS?

I am not aware of such requirement.  GNOME user manuals are installed
at /usr/share/gnome/help, perhaps KDE ones somewhere similar, maybe
Java/Mono docs go to a specialized directory as well, etc.

The average GNUstep developer/user expects to find GNUstep
documentation at $(GNUSTEP_<DOMAIN>_DOC), which is
/usr/share/GNUStep/Documentation with our layout.  See the output of
`dpkg -L gnustep-base-doc', for example.

I'll add a note to myself to mention this in the GNUstep Debian
packaging policy.

> [multiple packages]
> fixed, now it is much cleaner.

Indeed.  I looked at the PkgSplit page you gave reference to (I was
not aware about its existence until now), and some things there seem
just plain wrong to me.  I think it's a matter of personal taste,
mostly.  As long as the result it policy-compliant, there is no "one
true way" to do it.

>> I can feel your pain.  The best place to look at is the source code

> *sigh* Ok, i'll take a look :)

Well, DBModeler doesn't accept any options (besides the common GNUstep
ones), so the manpage can be mostly a stub explaining in a sentence or
two what the application does and a link to GNUstep(7) in the `SEE
ALSO' section.  See SimpleAgenda.1 for a very simple example (and many
other GNUstep apps, too).

For eoutil, all you need is to nroff-ify the output of `eoutil help'.
It is thoroughly documented, AFAICS.  No problem here, except some
mechanical work.

gdlgsdoc is a mystery to me, give me some time to take a look at it.


Some more comments:

* The package FTBFSes in a chroot: missing build-dependencies on
  texinfo and texlive-latex-base?  The precise failure is:

  dh_installdocs 
  cp: cannot stat `Documentation/GDL2Intro/GDL2Intro.pdf': No such file 
or directory
  dh_installdocs: cp -a Documentation/GDL2Intro/GDL2Intro.pdf debian/
gnustep-dl2/usr/share/doc/gnustep-dl2 returned exit code 1
  make: *** [binary-arch] Error 2

  But that's just a consequence of the (unpleasant) fact that
  gnustep-make ignores these kind of errors; looking in the build log:

  Making all for doc GDL2Intro...
  makeinfo -D NO-TEXI2HTML  \
                 -o GDL2Intro.info GDL2Intro.texi
  make[4]: makeinfo: Command not found
  make[4]: [GDL2Intro.info] Error 127 (ignored)
  texi2pdf   \
                   GDL2Intro.texi -o GDL2Intro.pdf
  make[4]: texi2pdf: Command not found
  make[4]: [GDL2Intro.pdf] Error 127 (ignored)

* In the binary-arch target, you do not invoke dh_installmenu so the
  .menu file is not installed.  Subsequently, the menu trigger is not
  activated.

* [Nice to have]  Both the .desktop and .menu file do not include
  icon.  Please consider the same trick as you did for preview.app.

* I: libgnustep-dl2-dev: arch-dep-package-has-big-usr-share 2328kB 84%

  GNUstep Make's `internal-install-doc_' rule is a bit dumb as it
  copies everything that `autogsdoc' spits out in the build dir.  Does
  this warning disappear if you delete all .gsdoc files in the -dev
  package in the `install' target right after installation?

* Please avoid compressing GDL2Intro.pdf.  Most PDF readers in Debian
  will happily read and render compressed PDF files, but unfortunately
  viewpdf.app (the "official" GNUstep PDF viewer we have) does not.

* Don't forget to recheck all files and update debian/copyright if
  needed.  As the package is going to pass through the NEW queue, the
  ftpmasters will inspect it with a certain degree of scrutiny.
  That's the most pleasant and rewarding part of Debian packaging :-))