gEDA-user: Comments: libgeda and fedora packaging

["Chitlesh GOORAH" <chitlesh.goorah@xxxxxxxxx>]

Hello there,

I don't recall if I have already sent a similar email before, but
below are some minor items that I want it to be fixed upstream. Most
of these have already being fixed in fedora (except the warnings
undefined-non-weak-symbol and shared-lib-calls-exit).

[root@cgoorah ~]# rpmlint libgeda
libgeda.i386: W: shared-lib-calls-exit /usr/lib/libgeda.so.33.0.1
exit@xxxxxxxxx
libgeda.i386: W: undefined-non-weak-symbol /usr/lib/libgeda.so.33.0.1
load_newer_backup_func
libgeda.i386: W: undefined-non-weak-symbol /usr/lib/libgeda.so.33.0.1
arc_draw_func
libgeda.i386: W: undefined-non-weak-symbol /usr/lib/libgeda.so.33.0.1
line_draw_func
libgeda.i386: W: undefined-non-weak-symbol /usr/lib/libgeda.so.33.0.1
text_draw_func
libgeda.i386: W: undefined-non-weak-symbol /usr/lib/libgeda.so.33.0.1
x_log_update_func
libgeda.i386: W: undefined-non-weak-symbol /usr/lib/libgeda.so.33.0.1
net_draw_func
libgeda.i386: W: undefined-non-weak-symbol /usr/lib/libgeda.so.33.0.1
select_func
libgeda.i386: W: undefined-non-weak-symbol /usr/lib/libgeda.so.33.0.1
complex_draw_func
libgeda.i386: W: undefined-non-weak-symbol /usr/lib/libgeda.so.33.0.1
circle_draw_func
libgeda.i386: W: undefined-non-weak-symbol /usr/lib/libgeda.so.33.0.1
box_draw_func
libgeda.i386: W: undefined-non-weak-symbol /usr/lib/libgeda.so.33.0.1 do_logging
libgeda.i386: W: undefined-non-weak-symbol /usr/lib/libgeda.so.33.0.1
bus_draw_func
libgeda.i386: W: undefined-non-weak-symbol /usr/lib/libgeda.so.33.0.1
pin_draw_func
libgeda.i386: W: undefined-non-weak-symbol /usr/lib/libgeda.so.33.0.1
picture_draw_func
libgeda.i386: W: unused-direct-shlib-dependency
/usr/lib/libgeda.so.33.0.1 /usr/lib/libpangocairo-1.0.so.0
libgeda.i386: W: unused-direct-shlib-dependency
/usr/lib/libgeda.so.33.0.1 /usr/lib/libpango-1.0.so.0
libgeda.i386: W: unused-direct-shlib-dependency
/usr/lib/libgeda.so.33.0.1 /usr/lib/libcairo.so.2
libgeda.i386: W: unused-direct-shlib-dependency
/usr/lib/libgeda.so.33.0.1 /lib/libgmodule-2.0.so.0

The warnings should be corrected.

static libraries /usr/lib64/*.la should be not be shipped. Shouldn't
the --disable-static solve this ?


In the fedora libgeda package, I ensure that libgeda owns the
directory /usr/share/doc/gEDA. In this directory I put all the docs
related to
- what is geda and friends
- how to use those tools

Thereby, the libgeda source package which contains some *.html and
*.png are pushed to /usr/share/doc/gEDA
install -d %{buildroot}%{_docdir}/gEDA/
install -pm 0644 docs/*.html   %{buildroot}%{_docdir}/gEDA/
install -pm 0644 docs/logo.png %{buildroot}%{_docdir}/gEDA/

Currently the libgeda-1.4.2 doesn't place these files during the make
install procedure. I would like if you (as upstream) could adopt such
directory structure, so that every distribution would not define his
own.

Below you will find some other directory ownership of the geda
packages, that the fedora libgeda and geda-symbols take care of:
# geda-symbols is the Owner of the following directories
#%dir %{_docdir}/gEDA/readmes
#%dir %{_docdir}/gEDA/man
#%dir %{_docdir}/gEDA/examples
#%dir %{_datadir}/gEDA/bitmap

# libgeda is the Owner of the following directories
#%dir %{_datadir}/gEDA
#%dir %{_datadir}/doc/gEDA/
#%dir %{_datadir}/gEDA/scheme

Wouldn't be nice if the locales should be libgeda.lang instead of
libgeda33.lang ?

# locale's
#find_lang libgeda33
if [ -d %{buildroot}%{_datadir}/locale/ ]; then
  for lang_dir in %{buildroot}%{_datadir}/locale/* ; do
    lang=$(basename $lang_dir)
    echo "%lang($lang)
%{_datadir}/locale/$lang/LC_MESSAGES/libgeda33.mo" >> %{name}.lang
  done
fi

At fedora, we got some strict packaging guidelines, thereby I will
send you some comments of other geda packages in separate emails(this
week). Thus I can track my requests :)

Kind regards,
Chitlesh


_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user