[Bug 168719] Review Request: gdal

bugzilla at redhat.com bugzilla at redhat.com
Wed Sep 21 18:05:06 UTC 2005


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 silke at intevation.de  2005-09-21 14:04 EST -------
(In reply to comment #6)
> (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.

Oops, you are of course right. Changed this with an updated version (see usual
place on our server).

> 
> > > - 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.

But I could link an application (in this case UMN MapServer) against gdal with
only having gdal-devel (and gd-devel with is necessary for UMN) installed on my
system.

gdal just creates something like an API to different raster and vector GIS
formats. So no information about postgresql, hdf, mysql etc. is needed to have
access to gdal. I furthermore checked the header files in /usr/include/gdal to
see which header files they include and they just need either other gdal-header
files or standards like stdio.h etc. So I am rather sure that the dependencies
are sufficient. Have I overseen something?


>  
> > > 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).

Most of these reasons are reasons against static linkage and for shared linkage
and I fully agree with you in this issue. Nevertheless if really someone would
like to statically link gdal I don't want my package to be the stopper - even if
I would probably never need it myself. 

> 
> 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.

OK. Thanks for this hint. Since I don't have a real preference on having the
*.la included or not I think I will wait what the reviewer will say about it.


-- 
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.




More information about the fedora-extras-list mailing list