Re: [q-lang-devel] Status of debian packaging

[Kari P. <ka...@sa...>]

On Mon, Feb 23, 2004 at 11:28:35PM +0100, Albert Graef wrote:
> Kari Pahula wrote:
> >I've begun building a Debian package of Q.  Some things I've changed
> >to make it conform more to Debian's standards:
> 
> Ok. I have my gripes with scattering stuff belonging to a package all 
> over the place, but if that's the standard under Debian, then so be it...

It's nice to have programs follow a uniform standard once you have
thousands of them.

> >I moved stuff away from share/q/etc and share/q/examples.
> 
> Did you move *all* the stuff in examples? (I'm asking because a FreeBSD 

I didn't touch the example installation parts of the makefiles, I just
let it install everything under /usr/share/q/examples and then mv it
where I like afterwards.  That should get them all.

> >In the package:
> >@dircategory Development
> >@direntry
> >* Q: (qdoc).                    The Q programming language and system.
> >@end direntry
> 
> Hmm, is that standard across different distros? Then I might add it to 

The nearest thing you got to a standard is the "Installing Info
Directory Files" page in texinfo's doc and the dir-example file
included with texinfo.  It has "Software development" category listed
in it, Q would fit under that.  That'd be better than leaving it
unspecified, IMHO.

I don't know why Debian has chosen to put most of its info docs under
"Development".  "Software development" is used too.  This isn't really
something anybody has bothered to make any official decision on.

> >Most of the packaging is done, but I'm stuck with the libraries.
> >Things work fine until I run automake again.
> 
> Yes, cvs had some files which should rather be regenerated when 

It's been a while since I've touched libtool, all my troubles were
mostly due to my own neglicience.  If in doubt, rebuild scripts...

> I'll provide a pointer to your page on the Q website asap. BTW, on which 

I've put packages of 5.1 at mentors.debian.net.  It's compiled now
with -O3.

> Debian system(s) will that package work? I guess that the different 
> library versions available will make it necessary to distribute separate 
> packages for woody, sarge and sid, no?

It's only for sid for now, but I'll try to find a sponsor for it and
get it included in Debian proper.  That'll take care of having
packages for sarge, too.  I wouldn't bother with backporting the
package to woody, sarge should be released in the near future anyway.

I hope you don't mind if I say a few things about the build system.
All of this is IMHO, of course.

I wouldn't bother to include readline with Q.  Trivial replacement for
readline is scanf.  That's what I've seen other projects do.

I wouldn't provide those --with-*-includes options.  The configure
script is supposed to find the required flags without user
intervention.  Ideally the only things the user should have to concern
himself with are where to install (--prefix and friends) and what to
install (--enable-* and --with-*).  And --with-libname is for a 'yes'
or 'no' input from the user, not the flag to pass to the compiler.

If you are using GNU extensions in glob and regex, then I guess it's
ok to include them.  I'm still changing the build system to use the
ones in glibc for my packages.

I would make a --with-ltdl option, which would use the system's
version if it's 'yes' and use the included one if 'no'.  That would be
a more uniform semantics than the special --with-installed-ltdl used
now.

And there's one genuine problem with the build system.  You are
building modules which use a library built in the same build.  You
have specified SUBDIRS = ... libq modules ... and rely on the order of
make in subdirectories for libq to be built.  You then add
-L$(top_builddir)/libq -lq in _la_LIBADD in the modules' Makefile.am
files.  This works, but that same flag ends up in dependency_libs in
the final installed .la file.  This may be an security risk, if that
path is writable by an user.

This is what dependency_libs in clib.la looks like in a pristine build:
dependency_libs=' -L/home/kari/dl/q-5.1/libq /usr/local/lib/libq.la /usr/lib/libgmp.la -lpthread -lcrypt -lutil -lnsl -lm'

I can think of two ways of preventing that extra -L ending up in
there.  The right way: build first anything but the modules, install
them, then build the modules, no need for any extra -L flags as libq
is already installed.  Or the hack: change the .la files themselves.
I did this for myself.  I did this after everything was installed:
        for a in $(CURDIR)/debian/q-lang/usr/lib/q/*.la;\
        do sed 's/-L[^ ]+libq//' -r < $$a >$$a.fixed;\
        mv $$a.fixed $$a; done

You might want to do something like that in your build too.