Raising to release blocker so we aren't forever stuck with this package providing something it shouldn't.

Priority: Normal => release_blocker

Indeed.
Why is it providing that many system libraries???

CC: (none) => thierry.vignaud

Another package moved them in %_libdir/harbour:
http://rpmfind.net/linux/rpm2html/search.php?query=harbour-contrib&submit=Search+...&system=&arch=
http://rpmfind.net/linux/rpm2html/search.php?query=harbour-libs&submit=Search+...&system=&arch=

See http://dl.atrpms.net/src/sl6-i386/atrpms/stable/harbour-3.0.0-11.src.rpm

The trick being:
make install\
(...)
     HB_INSTALL_LIB=%{buildroot}%{_libdir}/harbour \
     HB_INSTALL_DYN=%{buildroot}%{_libdir}/harbour \

Created attachment 6405 [details]
this does it

Thanks Thierry,
I'm testing and will commit later if package still works OK.

Thierry,
One of your changes to the make options was already set in the harbour build environment section of the spec - I have added the other in the same place:

%define hb_ldir        export HB_INSTALL_LIB=%{buildroot}%{_libdir}/%{name}
%define hb_ddir        export HB_INSTALL_DYN=%{buildroot}%{_libdir}/%{name}

I am now having problems with linking anything using qt.
Builds of applications that use Harbour core and contrib libs are OK.

A typical test build that I use runs OK with the current repo version:
------------------------
[baz@jackodesktop hbqt3]$ hbmk2 q3
Harbour 3.2.0dev (r1406271520)
Copyright (c) 1999-2014, http://harbour-project.org/
Compiling 'q3.prg'...
Lines 4840, Functions/Procedures 1
Generating C source output to '/tmp/hbmk_76gufz.dir/q3.c'... Done.
------------------------

This produces a working qt executable called q3.

With the patched build I hit this:

--------------------------------
[baz@jackodesktop hbq3]$ hbmk2 q3
Harbour 3.2.0dev (r1406271520)
Copyright (c) 1999-2014, http://harbour-project.org/
Compiling 'q3.prg'...
Lines 4840, Functions/Procedures 1
Generating C source output to '/tmp/hbmk_a9tn4g.dir/q3.c'... Done.
/tmp/hbmk_a9tn4g.dir/q3.o:(.data+0x70): undefined reference to `HB_FUN_QWIDGET'
/tmp/hbmk_a9tn4g.dir/q3.o:(.data+0x110): undefined reference to `HB_FUN_QLABEL'
/tmp/hbmk_a9tn4g.dir/q3.o:(.data+0x1f0): undefined reference to `HB_FUN_QAPPLICATION'
collect2: error: ld returned 1 exit status
hbmk2: Error: Running linker. 1
gcc '/tmp/hbmk_a9tn4g.dir/q3.o' '/tmp/hbmk_a9tn4g.dir/hbmk_ht9tde.o'   -Wl,--start-group -lhbcplr -lhbdebug -lharbour   -Wl,--end-group -oq3 -L/usr/lib64/harbour

 and add option
       'contrib/hbqt/qtgui/hbqtgui.hbc' for missing function(s):
       QAPPLICATION(), QLABEL(), QWIDGET()
----------------------------------

To run the test I have modified .hbc files in the build directory, as the qtcontribs addons for Harbour try to use the harbour build tree hierarchy to access some files relatively which does not work for a 'proper' linux package install. Maybe these need further modification for the new layout? I'm getting very lost :\

It's probably simple but I can't see it, any help would be appreciated.

I will attach a tarball of my test directory.

The patched build is in this repo:

http://mtf.no-ip.co.uk/pub/linux/barjac/distrib/cauldron/x86_64/media/extra/release/

(Probably best to install harbour-bundle which pulls everything in one go)

SRPM is here:
http://mtf.no-ip.co.uk/pub/linux/barjac/distrib/cauldron/SRPMS/harbour-3.2.0-2.19101.314.5.3.mga5.src.rpm

Created attachment 6417 [details]
hbqt3 test directory

This small test program can be built with the following run in the hbqt3 directory:

hbmk2 q3

This produces q3 which can be run with

./q3

It displays a red ball with a "click me to close" message on it.

Build fails with the updated version.

In comment #6 the output was somehow corrupted here it is again:

[baz@jackodesktop hbqt3]$ hbmk2 q3
Harbour 3.2.0dev (r1406271520)
Copyright (c) 1999-2014, http://harbour-project.org/
Compiling 'q3.prg'...
Lines 4840, Functions/Procedures 1
Generating C source output to '/tmp/hbmk_59smx6.dir/q3.c'... Done.
/usr/lib64/harbour/libhbqtgui.so: undefined reference to `HB_FUN_HB_QSCROLLERPROPERTIES'
/usr/lib64/harbour/libhbqtgui.so: undefined reference to `HB_FUN_QSURFACE'
/usr/lib64/harbour/libhbqtgui.so: undefined reference to `HB_FUN_QSCROLLER'
/usr/lib64/harbour/libhbqtcore.so: undefined reference to `HB_FUN_QMARGINSF'
/usr/lib64/harbour/libhbqtgui.so: undefined reference to `HB_FUN_HB_QPAGESIZE'
/usr/lib64/harbour/libhbqtcore.so: undefined reference to `HB_FUN_HB_QMARGINSF'
/usr/lib64/harbour/libhbqtgui.so: undefined reference to `HB_FUN_QPAGESIZE'
/usr/lib64/harbour/libhbqtgui.so: undefined reference to `HB_FUN_HB_QWINDOW'
/usr/lib64/harbour/libhbqtgui.so: undefined reference to `HB_FUN_QSURFACEFORMAT'
/usr/lib64/harbour/libhbqtgui.so: undefined reference to `HB_FUN_HB_QPAGELAYOUT'
/usr/lib64/harbour/libhbqtgui.so: undefined reference to `HB_FUN_QWINDOW'
/usr/lib64/harbour/libhbqtgui.so: undefined reference to `HB_FUN_HB_QSCROLLER'
/usr/lib64/harbour/libhbqtgui.so: undefined reference to `HB_FUN_QSCREEN'
/usr/lib64/harbour/libhbqtgui.so: undefined reference to `HB_FUN_QPAGELAYOUT'
/usr/lib64/harbour/libhbqtgui.so: undefined reference to `HB_FUN_HB_QSCREEN'
/usr/lib64/harbour/libhbqtgui.so: undefined reference to `HB_FUN_HB_QSURFACEFORMAT'
/usr/lib64/harbour/libhbqtcore.so: undefined reference to `HB_FUN_QSTANDARDPATHS'
/usr/lib64/harbour/libhbqtgui.so: undefined reference to `HB_FUN_HB_QSURFACE'
/usr/lib64/harbour/libhbqtcore.so: undefined reference to `HB_FUN_HB_QSTANDARDPATHS'
/usr/lib64/harbour/libhbqtgui.so: undefined reference to `HB_FUN_QSCROLLERPROPERTIES'
collect2: error: ld returned 1 exit status
hbmk2[q3]: Error: Running linker. 1
gcc '/tmp/hbmk_59smx6.dir/q3.o' '/tmp/hbmk_59smx6.dir/hbmk_5cvw5v.o'   -Wl,--start-group -lhbqtcore -lQtCore -lhbqtgui -lQtGui -l'stdc++' -lhbcplr -lhbdebug -lharbour   -Wl,--end-group -oq3 -L/usr/lib64/harbour

hbmk2: Hint: Install package hbqtgui and add option
       'contrib/hbqt/qtgui/hbqtgui.hbc' for missing function(s):
       QSCROLLERPROPERTIES(), HB_QSURFACE(), HB_QSURFACEFORMAT(), HB_QSCREEN(),
       QPAGELAYOUT(), QSCREEN(), HB_QSCROLLER(), QWINDOW(), HB_QPAGELAYOUT(),
       QSURFACEFORMAT(), HB_QWINDOW(), QPAGESIZE(), HB_QPAGESIZE(),
       QSCROLLER(), QSURFACE(), HB_QSCROLLERPROPERTIES()
hbmk2: Hint: Install package hbqtcore and add option
       'contrib/hbqt/qtcore/hbqtcore.hbc' for missing function(s):
       HB_QSTANDARDPATHS(), QSTANDARDPATHS(), HB_QMARGINSF(), QMARGINSF()

Decreasing priority as it's not release critical. Updates will fix it

Priority: release_blocker => High
CC: (none) => ennael1

Maybe you need to add "%{_libdir}/harbour" in /etc/ld.so.conf.d/harbour.conf?

Raising back to release_blocker.  Once this gets released in core/release, updates can never fix it, as it will still be providing the incorrect provides in those hdlists.  If this isn't "fixed fixed" before release, it will need to be dropped and reintroduced as an update afterward.

Priority: High => release_blocker

David, I will fix the provides issue, and ask for push. Will later tonight be early enough? I'm really pushed for time right now.

(In reply to Rémi Verschelde from comment #10)
> Maybe you need to add "%{_libdir}/harbour" in /etc/ld.so.conf.d/harbour.conf?

Thanks I will try later, but if not it can be fixed after release with an update I guess.

Yes, later tonight is totally fine.  Mageia 5 won't be released before the end of the week.  I think they're actually targeting next week currently.

(In reply to David Walser from comment #11)
> Raising back to release_blocker.  Once this gets released in core/release,
> updates can never fix it, as it will still be providing the incorrect
> provides in those hdlists.  If this isn't "fixed fixed" before release, it
> will need to be dropped and reintroduced as an update afterward.

I have removed the minilzo provides.

By leaving all the other contrib libs in %{_libdir} it still functions correctly building with hbqt.

The remainder in %{_libdir} below are mainly lib*hb* named which should not conflict with anything else. The exceptions are the three marked below, however these are also ONLY provided by harbour.

%files -n %{libcontrib}
%{_libdir}/libxhb.so*
%{_libdir}/librddsql.so*             <=====
%{_libdir}/libhbblink.so*
%{_libdir}/libhbbz2.so*
%{_libdir}/libhbcomm.so*
%{_libdir}/libhbct.so*
%{_libdir}/libhbexpat.so*
%{_libdir}/libhbformat.so*
%{_libdir}/libhbfoxpro.so*
%{_libdir}/libhbfship.so*
%{_libdir}/libhbgt.so*
%{_libdir}/libhbhpdf.so*
%{_libdir}/libhbhttpd.so*
%{_libdir}/libhblzf.so*
%{_libdir}/libhbmemio.so*
%{_libdir}/libhbmisc.so*
%{_libdir}/libhbmlzo.so*
%{_libdir}/libhbmxml.so*
%{_libdir}/libhbmzip.so*
%{_libdir}/libhbnetio.so*
%{_libdir}/libhbnf.so*
%{_libdir}/libhbsms.so*
%{_libdir}/libhbsqlit3.so*
%{_libdir}/libhbssl.so*
%{_libdir}/libhbtip.so*
%{_libdir}/libhbtpathy.so*
%{_libdir}/libhbunix.so*
%{_libdir}/libhbxpp.so*
%{_libdir}/libhbzebra.so*
%{_libdir}/librddbm.so*            <=====
%{_libdir}/libhbziparc.so*
%{_libdir}/libsddsqlt3.so*         <=====
%{_libdir}/libhbamf.so*
%{_libdir}/libhboslib.so*
%{_libdir}/libhbtest.so*
%{_libdir}/libhbtinymt.so*
%{_libdir}/libhbxdiff.so*

Is this acceptable?

Have you actually removed the minilzo files from the package and built it against the system one?

Also, the wildcard expressions should be %{_libdir}/libfoo.so.*  (note the dot before the *), as the package should not be providing .so files.  If those files are needed for something, they should be moved to a -devel package.

Keywords: PATCH => (none)

(In reply to David Walser from comment #16)
> Have you actually removed the minilzo files from the package and built it
> against the system one?

Ah no they are still in the sources however they should not now be used - but yes thanks - I will remove those sources before build to check.

> 
> Also, the wildcard expressions should be %{_libdir}/libfoo.so.*  (note the
> dot before the *), as the package should not be providing .so files.  If
> those files are needed for something, they should be moved to a -devel
> package.

Even in the case of a package which is by definition a development tool? i.e. it is a compiler/linker and as such is it not an exception to requiring a -devel?

OK it now deletes the zlib sources and patches the makefile to not build zlib locally.
The package still builds but I will look at it again tomorrow it's too late now and my eyes hurt :\

(In reply to Barry Jackson from comment #17)
> (In reply to David Walser from comment #16)
> > Have you actually removed the minilzo files from the package and built it
> > against the system one?
> 
> Ah no they are still in the sources however they should not now be used -
> but yes thanks - I will remove those sources before build to check.

OK, thanks.

> > Also, the wildcard expressions should be %{_libdir}/libfoo.so.*  (note the
> > dot before the *), as the package should not be providing .so files.  If
> > those files are needed for something, they should be moved to a -devel
> > package.
> 
> Even in the case of a package which is by definition a development tool?
> i.e. it is a compiler/linker and as such is it not an exception to requiring
> a -devel?

Yes.

(In reply to David Walser from comment #19)
Was that 'yes it's an exception' or 'yes it still requires a -devel' ?

(In reply to Barry Jackson from comment #20)
> (In reply to David Walser from comment #19)
> Was that 'yes it's an exception' or 'yes it still requires a -devel' ?

Yes they should still be in a -devel package.

They originally were a few years ago, then I decided that all the -devels were not really needed. I obviously misunderstood this at the time:

From Fedora packaging guidelines:
"There are some notable exceptions to this packaging model, specifically:
compilers often include development files in the main package because compilers are themselves only used for software development, thus, a split package model does not make any sense. 
When in doubt as to whether a file belongs in the base package or in -devel, packagers should consider whether the file is necessary to be present for a user to use or execute the functionality in the base package properly, or if it is only necessary for development. If it is only necessary for development, it must go into a -devel package."

I suppose that in this case the libs will be required at run time of built projects while the stuff in the -devels will not, so it looks like I had it right in the first place years ago :\

I will revert back to the way it was and remove all the obsoletes.

Any news? we will build new isos soon. Thanks

It sounded like Barry had something almost ready to go, hopefully he'll have it committed soon.  This package shouldn't be on the ISOs though, so it shouldn't have an impact on that.  This just needs to be resolved before we branch the mga5 tree on the mirrors.

Anne, Barry is posting this on the ml too, but he's got fixes committed, so you can push harbour and it should fix this.

Submitted. Please test so that we can close this bug

Confirmed fixed in harbour-3.2.0-2.19101.314.6.mga5.  Thanks Barry!

Status: NEW => RESOLVED
Resolution: (none) => FIXED