> > 1. I used the 10.2 src.rpms as base and just cleaned up the spec files
> and
> > added missing dependencies. The only needed patches were the $DESTDIR
> ones.
>
> Are the dependencies release specific or are we missing some?
I don't think that they are release specific but more because the build root
is pretty much stripped down so it doesn't contain stuff which you might
consider normally available. E.g.:
(your Requires vs. mine Requires)
* openvas-client: openssl-devel gtk2-devel gettext-devel gcc-c++ vs.
gtk2-devel openssl-devel
* openvas-libnasl: openvas-libraries-devel vs. bison gnutls-devel
libgcrypt-devel libgpgme-devel libpcap-devel openvas-libraries-devel
texlive-latex
* openvas-libraries: gnutls-devel vs. libpcap-devel gnutls-devel
* openvas-plugins: openvas-server-devel vs. gnutls-devel libpcap-devel
openvas-libraries-devel openvas-server-devel
* openvas-server: openvas-libnasl-devel vs. gnutls-devel libgcrypt-devel
libpcap-devel openvas-libnasl-devel openvas-libraries-devel
The rest was just writing init & logrotate files for openvasd and general
cleanup in the spec files (e.g. install instead of mkdir & cp, macros
instead of commands, adding ldconfig et al to PreReq) and so on.
> > 4. The certificates that are generated for the server end up in
> > /usr/com/openvas/CA/, which is, to the best of my knowledge, at least
> > unorthodox. If one doesn't use already existing certificates but the
> > generated ones they would be specific for that service / server and
> > therefore should be in /var/lib/openvas/CA/ or /etc/openvas too to
> prevent
> > clutter.
>
> Interesting, on Debian they end up in /var/lib/openvas/CA. Are you
> applying
> the patch? I think openvas-server trunk fixes it, but the
> original ./configure defines localstatedir as PREFIX/com (which is where
> your
> problems are probably coming from). The patched Makefile over rules this.
That one was my bad - apologies! I overlooked that %configure resulted in
configure getting called with "--sharedstatedir=/usr/com". Changing this
into "--sharedstatedir=%{_localstatedir}/lib" fixed it (the patch was
applied on both versions).
> > 6. I haven't found a way to point the client to the correct manual
> > location. It always tries to load
> > /usr/share/doc/OpenVAS/users-manual-de.pdf which doesn't exist since I
> > configured the openvas-manual rpm to put its content into the clients doc
> > directory (/usr/share/doc/packages/openvas-client/)
>
> This is a bug, I have changed openvas-client trunk to look for the manual
> in
> PREFIX/share/doc/openvas-manual.
Much better than before although I would consider -client instead of -manual
more fittingly since it is only the client manual (at least all I have seen
was about the client) or the possibility to define the path via some
Makefile parameter so everyone can configure it to its preferences.
Thanks a lot for the fast response / fixes
Stephan
_______________________________________________
Openvas-devel mailing list
[email protected]
http://lists.wald.intevation.org/mailman/listinfo/openvas-devel
