[Bug 168719] Review Request: gdal

[bugzilla at redhat.com]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.

Summary: Review Request: gdal


https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168719





------- Additional Comments From rc040203 at freenet.de  2005-09-21 03:16 EST -------
(In reply to comment #4)
> (In reply to comment #2)
> > 

> Yes you are right. Using internal libtiff has historical reasons and I forgot
> to change it.
You still seem to have forgotten it ;)

BuildRequires: libtiff-devel >= 3.60
configure ... --with-libtiff ...

Without this, building gdal inside of a chroot will build the internal libtiff.

> > - Probably a lot of missing package deps inside of devel package.
> > (c.f. /usr/lib/libgdal.la)
> 
> As far as I can see the dependencies are sufficient. gdal-devel is sufficient to
>  build other packages against gdal. I tried with mapserver after removing all
> other devel-packages on my system.
Hmm, libgal is linked against various libraries. Normally you will not be able
to link against libgal unless you have all devel packages corresponding to these
libraries installed.

AFAIS, this comprises:
openssl-devel
libjpeg-devel
libungif-devel
hdf5-devel
mysql-devel
netcdf-devel
unixODBC-devel
libpng-devel
postgresql-devel
sqlite-devel
libtiff-devel
zlib-devel
and probably more (e.g. xorg-x11-libs).
 
> > Additional remarks:
> > - I recommend not to ship static libs.
> 
> Why? Mostly static libs are not needed but if someone really needs the 
> static lib it is nice to have it available.
The reasons are:
* Maintainability/bugfixing: Unless a library's ABI/API changes, exchanging a
shared lib often is sufficient.
* Statically linked applications are easy to miss when fixing security issues.
* Package bloat
* Static linkage is rarely used and even less rarely required.
* Avoiding potential licensing issues (static linkage vs. shared linkage makes a
substantial difference licensing-wise).

All in all, IMO, static libs cause more troublesome than they are useful, but
that's just my personal preference.

> > - Other reviewers probably will gripe on shipping libtool archives, but my
> > opinion differs (This is a different story ;) ).
> 
> Ack. I can easily remove it. But I think it doesn't hurt to have it available.
> It is still included in the current package.
Fine with me - I consider *.la's to be part of a package's API and removing them
to imply breaking the API ;)

Note: If you decide to ship *.la's, you can't easily remove them, after a
package has been released, because other *.la's depending on them will pickup
references to them. I.e. once they are in, you're better off keeping them or you
will have to recompile all other libs depending on the *.la.

-- 
Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.