Status of SER & OpenSER packaging ?

[Julien BLACHE]

Julien BLACHE <jblache at debian.org> wrote:

Hi,

> I'll probably take a deeper look at the packages this week, and I may
> even add them to our SVN if I can get the packages in good shape
> (which is not the case right now, as the issues raised a few weeks ago
> aren't fixed yet -- versioning, non-native packaging, lintian
> warnings to begin with).

I've got test packages ready, you can get the sources at
<http://people.debian.org/~jblache/openser/>

The packages are based on the ones from openser.org, with the
following changes :

  - everything debconf-related got removed; setting up an HA cluster
    is an advanced use of OpenSER which cannot be handled through
    debconf anyway. The debconf support was really only a potential
    source of problems in the packaging.
  - build with TLS by default; do not worry about libssl, as long as
    the license exception is there (which is the case, IIRC), because
    it's installed on every system anyway
  - add missing build-depends: zlib1g-dev, flex, bison; fix the
    libradiusclient-ng-dev and libmysqlclient15-dev build-depends.
  - simplify debian/rules.
  - move some files from the openser package to the modules packages
    (radius, mysql, postgresql).
  - sanitize the build system: building with -O9 -funroll-loops isn't
    appropriate. Debian Policy mandates -Wall -g -O2. Additional
    options like -minline-all-stringops might prove useful for
    openser, so they could be re-added later.
    CFLAGS are set in debian/rules and Makefile.defs is patched to
    honor CFLAGS if already set.
  - strip the binaries, as per Policy. If you really want to be able
    to debug a crash, a -dbg package can be generated for this
    purpose, containing the debug symbols.
  - install a proper default file instead of creating it in the
    postinst.
  - touch+chown+chmod the radius seqfile at startup in the init
    script, instead of doing it in the postinst. Moreover, if the
    seqfile must survive a reboot, it must be moved to another
    directory, because /var/run should be cleaned at boot (FHS).

About the CFLAGS: the highest optimization level known to gcc is
-O3. -O9 does *nothing* more.


Some modules (like postgresql) do not build on non-i386
architectures. Is there a reason for that, and can that be fixed ?


Waiting for some feedback now :)

JB.

-- 
 Julien BLACHE - Debian & GNU/Linux Developer - <jblache at debian.org> 
 
 Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 
 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169