Re: 3.1.20

[Davide Barbieri <paci@prosa.it>]

On Thu, Jul 08, 1999 at 01:17:40AM +0200, Ulric Eriksson wrote:
 > On Tue, 6 Jul 1999, Davide Barbieri wrote:
 > >  	I'm the mantainer for Debian of the siag package.
 > >  I have some complain to do, if I can ... :-).
 > Welcome as maintainer, and complain on! ;-)

 Thank you :-).

 > >  1) runcmd has no man pages; this is considered a bug
 > >     in Debian; is it worth creating one, or should
 > >     I simply link runcmd.1 to undocumented.7?
 > I wrote a tiny manpage for runcmd today. It'll be in 3.1.21.

 Good! Thank you for your quick response.

 > Hacking the makefiles (or rather, Makefile.am and configure.in) is
 > certainly possible, and I invite anyone who wants custom targets like that
 > to contribute patches. Beware, though, that it can be tricky to sort out
 > which programs depend on what files.

 Have you see what we have done with siag office on Debian?
 We have

 xsiag
 xpw
 egon
 tsiag
 siag-common
 siagoffice-common
 siagoffice-plugins

 It shouldn't difficult to hack the Makefile in order to
 obtain this. I will try it, if you don't mind.

 > I also have to say that if it were my choice, which it isn't, I wouldn't
 > split the package. A gzipped tarball of everything "make install-strip"
 > installs, with dynamically linked executables, fits on a single floppy.

 This is policy debian. We prefere to give the user the possibility
 to install only the parts they need. If they want to install
 all of them, it is not difficult with a packet manager like
 dpkg (and his front-end apt).

 > That isn't exactly a heavyweight compared to many other programs these
 > days. And it may not be obvious to everyone that installing PW without the
 > spreadsheet leaves you with a word processor incapable of displaying
 > tables, which to me seems like a high price to pay for saving 0.3 MB of
 > disk space. Another example is Xfiler, which expects Xedplus to be
 > available for displaying text files.

 I think that the makefile can be split to have several target
 and also one general target that will install everything.
 This would do the trick to both offer flexibility and easy
 installation for newbie.

 > >  3) why Siag use /usr/libexec? This is not FHS compliant ...
 > It is FSF compliant. ;-) Seriously though, you can put the plugins (which
 > is the only thing Siag uses libexecdir for) anywhere by running configure
 > like this:
 > 
 > ./configure --libexecdir=/usr/lib	# or wherever
 > 
 > They end up in /usr/[local/]libexec by default because it is the default
 > libexecdir in the makefiles generated by automake/autoconf.

 Yes, infact I have used --libexecdir=/usr/lib when I built
 the Debian packages. Anyway, if I don't do so, and install
 on /usr/libexec, our lintian package (a program which verify
 the correctness of a debian package) complain that installing
 something in /usr/libexec is not FHS compliant. 
 I check the FHS document, and I found that it is so.

 Anyway, it is not a big problem at all: I can live well
 with --libexecdir option :-)

 Thanks,
 ciao
-- 
Davide Barbieri 
paci@prosa.it   - http://www.prosa.it/   - commercial opensource support
paci@debian.org - http://www.debian.org/ - opensource linux distribution