Bug 168719 - Review Request: gdal
Review Request: gdal
Status: CLOSED DUPLICATE of bug 205955
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Ralf Corsepius
Fedora Package Reviews List
http://ftp.intevation.de/freegis/fedo...
:
Depends On:
Blocks: FE-DEADREVIEW
  Show dependency treegraph
 
Reported: 2005-09-19 14:55 EDT by Silke Reimer
Modified: 2007-11-30 17:11 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-06-07 10:10:58 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Silke Reimer 2005-09-19 14:55:55 EDT
Spec Name or Url: http://ftp.intevation.de/freegis/fedora/4/SPECS/gdal.spec
SRPM Name or Url: http://ftp.intevation.de/freegis/fedora/4/SRPMS/gdal-1.3.0-1.src.rpm
Description:GDAL is a translator library for raster geospatial data formats. As a library, 
it presents a single abstract data model to the calling application for all
supported formats. The related OGR library (which lives within the GDAL source
tree) provides a similar capability for simple features vector data.

GDAL supports 40+ popular data formats, including commonly used ones (GeoTIFF,
JPEG, PNG and more) as well as the ones used in GIS and remote sensing software
packages (ERDAS Imagine, ESRI Arc/Info, ENVI, PCI Geomatics). Also supported
many remote sensing and scientific data distribution formats such as HDF, EOS
FAST, NOAA L1B, NetCDF, FITS.

OGR library supports popular vector formats like ESRI Shapefile, TIGER data,
S57, MapInfo File, DGN, GML and more.

------------------------
This is my first package for Fedora 4 so I am seeking a sponsor.

Some additional information:
============================
The package is an update of the package discussed about a year ago for fedora 2 (see https://bugzilla.fedora.us/show_bug.cgi?id=1964). 

I tried to clean all issues but still have a few rpmlint errors resp. warnings:

I don't know how to get rid of the following two errors:
E: gdal-debuginfo script-without-shellbang /usr/src/debug/gdal-1.3.0/frmts/jpeg/gdalexif.h
E: gdal-debuginfo script-without-shellbang /usr/src/debug/gdal-1.3.0/alg/gdal_tps.cpp

I couldn't find any hint in the guidelines which documentation should be included at least in a package. Could you please give a pointer so that I can fix this warning?
W: gdal-python no-documentation

Greetings,

       Silke
Comment 1 Ignacio Vazquez-Abrams 2005-09-19 15:24:45 EDT
(In reply to comment #0)
> I don't know how to get rid of the following two errors:
> E: gdal-debuginfo script-without-shellbang
/usr/src/debug/gdal-1.3.0/frmts/jpeg/gdalexif.h
> E: gdal-debuginfo script-without-shellbang
/usr/src/debug/gdal-1.3.0/alg/gdal_tps.cpp

For some reason these files are marked as executable in the source tarball. Fix
the permissions in %prep and this will disappear.

> I couldn't find any hint in the guidelines which documentation should be
included at least in a package. Could you please give a pointer so that I can
fix this warning?
> W: gdal-python no-documentation

Samples are always a good call.
Comment 2 Ralf Corsepius 2005-09-20 00:25:14 EDT
Not a formal review, just some comments:

+ A lot of progress since the last iteration

The package seems basically OK to me, nevertheless there still are some major
gripes, therefore I can avoid:

NEEDSWORK

- Is there a particular reason for using the internal libtiff?
I recommend using the version being shipped with FC, if possible. AFAIS, the
version shipped with FC4 seems to be sufficient, I haven't check other versions.


- Building the internal libtiff pulls in parts from the private copy of zlib
(AFAIS, they compile against the internal headers, but link against the external
libz):
# grep zlib log
/bin/sh ../../../libtool --mode=compile gcc -c -I../../../port -O2 -g -pipe
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -m32 -march=i386 -mtune=pentium4
-fasynchronous-unwind-tables -I/usr/include/netcdf-3 -I../../../port 
-DZIP_SUPPORT -DPIXARLOG_SUPPORT -I../../zlib -DJPEG_SUPPORT tif_aux.c -o
../../o/tif_aux.o
...
Using the external libtiff seems to avoid this issue.


- Something doesn't seem to be correct with mysql-support.
If building the package outside of buildroots (with mysql-devel installed),
mysql support is being built in, but I can't spot any corresponding
"BuildRequires:".
=> Non deterministic build results

I recommend to either switch it off (--with-mysql=no) or to make it mandatory
(BuildRequires: mysql-devel/--with-mysql).


- Similar consideration on hdf5 (hdf5 is part of FE).
If building the package outside of buildroots (with hdf5-devel installed), hdf5
support is picked up.
=> Non deterministic build results

I recommend to either switch it off (--with-hdf5=no) or to make it mandatory
(BuildRequires: hdf5-devel/--with-hdf5).

- Probably a lot of missing package deps inside of devel package.
(c.f. /usr/lib/libgdal.la)


Additional remarks:
- I recommend not to ship static libs.

- Other reviewers probably will gripe on shipping libtool archives, but my
opinion differs (This is a different story ;) ).
Comment 3 Silke Reimer 2005-09-20 07:06:12 EDT
According to Comments 1 and 2 I prepared a new package now available at
http://ftp.intevation.de/freegis/fedora/4/SRPMS/gdal-1.3.0-2.src.rpm The locate
for the specfile is the same as before:
http://ftp.intevation.de/freegis/fedora/4/SPECS/gdal.spec

Please see my additional remarks to both comments in direkt reply.
Comment 4 Silke Reimer 2005-09-20 07:08:33 EDT
(In reply to comment #2)
> 
> NEEDSWORK
> 
> - Is there a particular reason for using the internal libtiff?
> I recommend using the version being shipped with FC, if possible. AFAIS, the
> version shipped with FC4 seems to be sufficient, I haven't check other versions.

Yes you are right. Using internal libtiff has historical reasons and I forgot to
change it.

> - Something doesn't seem to be correct with mysql-support.
[...]
> 
> I recommend to either switch it off (--with-mysql=no) or to make it mandatory
> (BuildRequires: mysql-devel/--with-mysql).
> 
> 
> - Similar consideration on hdf5 (hdf5 is part of FE).
[...]

This is fixed with the new gdal package (See comment #3).

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

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

> 
> - 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.
Comment 5 Silke Reimer 2005-09-20 07:11:06 EDT
(In reply to comment #1)
> (In reply to comment #0)
> > I don't know how to get rid of the following two errors:
> > E: gdal-debuginfo script-without-shellbang
> /usr/src/debug/gdal-1.3.0/frmts/jpeg/gdalexif.h
> > E: gdal-debuginfo script-without-shellbang
> /usr/src/debug/gdal-1.3.0/alg/gdal_tps.cpp
> 
> For some reason these files are marked as executable in the source tarball. Fix
> the permissions in %prep and this will disappear.

Thanks for this hint. This is fixed in the new package (see Comment #3)


> > I couldn't find any hint in the guidelines which documentation should be
> included at least in a package. Could you please give a pointer so that I can
> fix this warning?
> > W: gdal-python no-documentation
> 
> Samples are always a good call.

Hm. The samples are already included either as python modules or as python
scripts in /usr/bin since they are not only samples but very useful tools. Thus
I don't think that including them as samples for documentation is a good idea.

Comment 6 Ralf Corsepius 2005-09-21 03:16:04 EDT
(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.
Comment 7 Silke Reimer 2005-09-21 14:04:59 EDT
(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.
Comment 8 Ralf Corsepius 2005-09-21 22:58:10 EDT
(In reply to comment #7)
> (In reply to comment #6)
> > (In reply to comment #4)
> > > (In reply to comment #2)

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

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

Yes,

* check the output of
nm -sDC libgdal.so.1.8.0  | grep ' U '

libgdal.so.1.8.0 uses other libraries. In your testcase you probably just happen
to get away luckily, because your application just seems to happen not to use
functions from these other libs.

* The gdal headers use headers from other packages:
# cd /usr/include/gdal
# grep \#include *.h | sed 's,.*[\"\<]\(.*\)[\"\>],\1,' | \
while read a; do if [ ! -f $a ]; then echo "$a"; fi; done
sql.h
sqlext.h
...

> > > > Additional remarks:
> > > > - I recommend not to ship static libs.

> 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. 
The point is: Probably nobody uses them! 

The only reason I can imagine for wanting to use static libs is application
vendors to ship application binaries, which are supposed to be "distribution
independent". From a distribution's view this doesn't make sense, because all
dependencies inside of the distribution can resolved inside of the distribution.
Comment 9 Silke Reimer 2005-10-17 12:25:04 EDT
(In reply to comment #8)
> (In reply to comment #7)
> > (In reply to comment #6)
> > > (In reply to comment #4)
> > > > (In reply to comment #2)

Sorry for my late answer. I have been busy with some preparation of a fair and
ill afterwards. But now I am finally back to packaging GIS software :-)

> 
> > > > > - 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.
> 
> > 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?
> 
> Yes,

You were right. I ran into the problem when I packaged another more complicated
software using gdal which is called qgis. I now added all (at least I think so)
necessary dependencies.

Furthermore I build a new version of the package, since meanwhile gdal 1.3.1 has
become available. Please look again at http://ftp.intevation.de/freegis/fedora/4/

Many thanks so far for all your comments.

         Silke
Comment 10 Ignacio Vazquez-Abrams 2005-12-27 00:43:37 EST
- Drop static libs and .la files everywhere
- Consider including pymod/samples in -python %doc
Comment 11 Silke Reimer 2006-03-14 09:12:13 EST
(In reply to comment #10)
> - Drop static libs and .la files everywhere
> - Consider including pymod/samples in -python %doc

OK. I have changed this. Furthermore I have recompiled gdal fro FC 5. The new
specfile and SRPMS are available at
http://ftp.intevation.de/freegis/fedora/5

The output of rpmlint is:

W: gdal unstripped-binary-or-object /usr/lib/libgdal.so.1.9.0
W: gdal-bin unstripped-binary-or-object /usr/bin/gdal_contour
W: gdal-bin unstripped-binary-or-object /usr/bin/gdaltindex
W: gdal-bin unstripped-binary-or-object /usr/bin/gdal_translate
W: gdal-bin unstripped-binary-or-object /usr/bin/ogr2ogr
W: gdal-bin unstripped-binary-or-object /usr/bin/ogrtindex
W: gdal-bin unstripped-binary-or-object /usr/bin/gdaladdo
W: gdal-bin unstripped-binary-or-object /usr/bin/gdalwarp
W: gdal-bin unstripped-binary-or-object /usr/bin/ogrinfo
W: gdal-bin unstripped-binary-or-object /usr/bin/gdalinfo

Should I strip the binaries and libraries manually or can I ignore these warnings?


Comment 12 Ralf Corsepius 2006-03-14 09:31:08 EST
(In reply to comment #11)

> W: gdal-bin unstripped-binary-or-object /usr/bin/gdalinfo
> 
> Should I strip the binaries and libraries manually or can I ignore these warnings?

Neither. RPM is supposed to strip binaries in /usr/bin automatically.

I.e. this indicates a serious problem elsewhere, which needs to be investigated.
Comment 13 Silke Reimer 2006-03-14 11:28:14 EST
(In reply to comment #12)
> (In reply to comment #11)
> 
> > W: gdal-bin unstripped-binary-or-object /usr/bin/gdalinfo
> > 
> > Should I strip the binaries and libraries manually or can I ignore these
warnings?
> 
> Neither. RPM is supposed to strip binaries in /usr/bin automatically.
> 
> I.e. this indicates a serious problem elsewhere, which needs to be investigated.
> 

I checked this again. For debugging purposes I added 'set -x' to
/usr/lib/rpm/brp-strip and found out that at least all binaries are stripped
with -g option:
strip -g /var/tmp/gdal-1.3.1-2-root-silke/usr/bin/gdaltindex

Any ideas how I can proceed to debug the problem?




Comment 14 Ralf Corsepius 2006-03-14 12:12:09 EST
2 issues:

* Package doesn't acknowledge $RPM_OPT_FLAGS.
The cause is the -fPIC hack inside of the spec file is overriding CFLAGS and
CXXFLAGS, instead of combining -fPIC and $RPM_OPT_FLAGS.

You probably want 
CFLAGS="-fPIC $RPM_OPT_FLAGS" \
CXXFLAGS="-fPIC $RPM_OPT_FLAGS" \
%configure ...

or similar.

* These two manpages from *-bin:
/usr/share/man/man1/pct2rgb.py.1.gz
/usr/share/man/man1/rgb2pct.py.1.gz
should be moved to *-python, because the executables they refer to are in *-python.

Comment 15 Michael Schwendt 2006-03-18 10:47:17 EST
> /usr/lib/rpm/brp-strip

You should have /usr/lib/rpm/redhat/brp-strip which is part of 
the "redhat-rpm-config" package which in turn is available if
"fedora-rpmdevtools" are installed.
Comment 16 Ignacio Vazquez-Abrams 2006-04-19 22:44:00 EDT
Ping?
Comment 17 Ralf Corsepius 2006-04-28 10:31:20 EDT
(In reply to comment #16)
> Ping?
I think, this PR has been lingering around long enough and should be closed to
give others who might be more interested into this package that the OP an
opportunity to take over.

Comment 18 Rudolf Kastl 2006-05-18 19:59:38 EDT
if anyone is interested i got a patch around that makes dynamically building vs
hdf4 possible. just lemme know.
Comment 19 Ralf Corsepius 2006-05-30 06:06:26 EDT
Ignacio, are you still reviewing this review request?

I think this PR has exceeded all reasonable limits and should be closed now.

Comment 20 Rudolf Kastl 2006-06-02 08:44:42 EDT
#19 where can i read up about the time limit policy for review requests?
if something like that doesent exist theres no time limits at all in my eyes.
Comment 21 Ralf Corsepius 2006-06-02 09:34:06 EDT
(In reply to comment #20)
> #19 where can i read up about the time limit policy for review requests?
Nowhere. IMO, Silke is simply AWOL and has left this Review request behind.
 
> if something like that doesent exist theres no time limits at all in my eyes.
Jerks "stopping by and dropping a Review bomb" don't help anybody. They should
be sanctioned.

If Fedora doesn't have a policy on this, it should be implemented.
Comment 22 Rudolf Kastl 2006-06-02 09:58:07 EDT
(In reply to comment #21)
> (In reply to comment #20)
> > #19 where can i read up about the time limit policy for review requests?
> Nowhere. IMO, Silke is simply AWOL and has left this Review request behind.
>  
> > if something like that doesent exist theres no time limits at all in my eyes.
> Jerks "stopping by and dropping a Review bomb" don't help anybody. They should
> be sanctioned.
> 
> If Fedora doesn't have a policy on this, it should be implemented.
> 
#21
well then instead of posting in tons of review requests id suggest to work on
getting a policy out that doesent hurt progress.

you see everything from a rather negative side. i dont see it as review bomb.
more as work in progress. maybe at some point circumstances dont allow the
initial poster to continue. closing the bug though will only make the time
invested by anyone involved "wasted time"

why not deal with it rather in a manner as with orphaned packages -> orphaned
review request. someone else can take over and can continue to work on the
existing base.

i want progress not wheel reinvention by having someone else starting from
scratch and having all the stuff repeated over and over.

gdal is an important key component for various interesting things.

well its a bit offtopic to discuss that here but "blackmailing" review requests
is just not the right approach in my eyes... instead wheres the rfe for enhanced
review rules?

also e.g. in the case of initng ... if you want software that fits well into
fedora, fedora people have to have an organized way to work through the stuff.
the more replys the more interest into a package -> the more progress

and progress and final output is all that really counts in my eyes. everything
else is just a waste of all our time.

hope you dont take the response as offensive.. its not meant to be. just my
opinion on the case.
Comment 23 Paul Howarth 2006-06-02 10:25:32 EDT
(In reply to comment #22)
> why not deal with it rather in a manner as with orphaned packages -> orphaned
> review request. someone else can take over and can continue to work on the
> existing base.

FWIW, something similar happened with milter-regex. I was reviewing it and found
it sufficiently interesting that I started using the package myself. For
whatever reason, the original poster lost interest in it and after a few
unanswered requests, I resubmitted the package myself and closed the original
review request as a duplicate of my new one. Somebody else then reviewed "my"
package, and it's now in Extras.

Comment 24 Ralf Corsepius 2006-06-02 10:37:49 EDT
In reply to comment #22)

> > Jerks "stopping by and dropping a Review bomb" don't help anybody. They should
> > be sanctioned.
> > 
> > If Fedora doesn't have a policy on this, it should be implemented.
> > 
> #21
> well then instead of posting in tons of review requests id suggest to work on
> getting a policy out that doesent hurt progress.

> i dont see it as review bomb.
I do. Just have a look at the timeline of Silke's responses. There are many
months inbetween any response of hers. Have a look at how many times she had
been asked to respond, ... nothing much since ...
Finally, this is not the first incident of this type with Silke - IIRC, the same
has happened in Fedora.US. - So, I am not negative, I am drawing conclusions
based on former contacts with her.

As it seems to me, her opinion is, she can "stop by", "drop her spec" and let
others polish it - She should learn she's in error.

> why not deal with it rather in a manner as with orphaned packages -> orphaned
> review request. someone else can take over and can continue to work on the
> existing base.
I am opposed to doing this, because this would encourage people to perform
"drive-by review request bombs". Instead, people should to understand that if
they submit a package for review, it's their baby they are dropping and they'll
be expected to take care about it in future.

If that's not acceptable to them, they 'd better stay away from FE.
 
> i want progress not wheel reinvention by having someone else starting from
> scratch and having all the stuff repeated over and over.
Well, I am not opposed in somebody else adopting Silke's package. But it won't
be me - I am not her coding-monkey. 

> gdal is an important key component for various interesting things.
Exactly, that's why I want to see this "damn thing" nailed down.

Actually, I want
* Silke to wake up and start cooperating
 or 
* some volunteer to take over her package
 or
* somebody closing this RR, giving others the liberty of resubmitting a new one.

> also e.g. in the case of initng ...
initng and my other very friend elektra are completely different cases. IMO,
these packages are a million miles away off from being ready for public use.

In case of gdal the situation different: This simply is a case of a submitter
being non-responsive for reasons I can only speculate on. 

> hope you dont take the response as offensive.. its not meant to be.
Understood.

Comment 25 Shawn McCann 2006-06-02 12:44:23 EDT
Regarding gdal, I'd be happy to finish this one off if there are no other
volunteers. It's a bit of a beast due to the dependencies and testing whether
the package is working right is also time consuming. But, as Rudolf noted, this
package is key to getting the open-source GIS packages into Fedora (QGIS, Grass,
etc) and until its approved, Fedora won't have any GIS applications in the
extras repository.

I had a package ready last fall but then saw that this submission was already in
progress. I exchanged emails with Silke back in January to see if she wanted any
help getting this finished off, but haven't pushed to get closure.

My vote is to declare this an orphan package and let someone else take it over
and finish it off (either by starting fresh or fixing up what exists).
Comment 26 Rudolf Kastl 2006-06-02 15:46:19 EDT
(In reply to comment #25)
> Regarding gdal, I'd be happy to finish this one off if there are no other
> volunteers. It's a bit of a beast due to the dependencies and testing whether
> the package is working right is also time consuming. But, as Rudolf noted, this
> package is key to getting the open-source GIS packages into Fedora (QGIS, Grass,

This and the key to next generation game development. i just finished off doing
basic packaging of delta3d and all its dependencies... some require a ton of
selfwritten patches. i am just about to get stuff upstream and polish
everything. i have a full blown gdal package btw... builds on fc5 with all deps
dynamically that are important and free.

i might put up the yet in extras missing stuff into a special repository on
newrpms. some things require more work. and i wont be able to maintain it all. i
am just interested in delta3d itsself.

if you take over the package we could get in further contact and id be happy to
pass you my current work so you can merge stuff you want in. id be also willing
to help you with all issues i can help with.

> etc) and until its approved, Fedora won't have any GIS applications in the
> extras repository.
> 
> I had a package ready last fall but then saw that this submission was already in
> progress. I exchanged emails with Silke back in January to see if she wanted any
> help getting this finished off, but haven't pushed to get closure.
> 
> My vote is to declare this an orphan package and let someone else take it over
> and finish it off (either by starting fresh or fixing up what exists).
> 
Comment 27 Rudolf Kastl 2006-06-02 16:01:23 EDT
(In reply to comment #24)
> In reply to comment #22)
> 
> > > Jerks "stopping by and dropping a Review bomb" don't help anybody. They should
> > > be sanctioned.
> > > 
> > > If Fedora doesn't have a policy on this, it should be implemented.
> > > 
> > #21
> > well then instead of posting in tons of review requests id suggest to work on
> > getting a policy out that doesent hurt progress.
> 
> > i dont see it as review bomb.
> I do. Just have a look at the timeline of Silke's responses. There are many
> months inbetween any response of hers. Have a look at how many times she had
> been asked to respond, ... nothing much since ...
> Finally, this is not the first incident of this type with Silke - IIRC, the same
> has happened in Fedora.US. - So, I am not negative, I am drawing conclusions
> based on former contacts with her.

Yes i can see that. i can also see your point of view. but in the end the really
important stuff is to change things in general. so there must be a good solution
 about this.

> 
> As it seems to me, her opinion is, she can "stop by", "drop her spec" and let
> others polish it - She should learn she's in error.
> 
> > why not deal with it rather in a manner as with orphaned packages -> orphaned
> > review request. someone else can take over and can continue to work on the
> > existing base.
> I am opposed to doing this, because this would encourage people to perform
> "drive-by review request bombs". Instead, people should to understand that if
> they submit a package for review, it's their baby they are dropping and they'll
> be expected to take care about it in future.
> 
> If that's not acceptable to them, they 'd better stay away from FE.
>  
> > i want progress not wheel reinvention by having someone else starting from
> > scratch and having all the stuff repeated over and over.
> Well, I am not opposed in somebody else adopting Silke's package. But it won't
> be me - I am not her coding-monkey. 

no one wants to push you into the role of the maintainer. seriously wasnt my
intention.

> 
> > gdal is an important key component for various interesting things.
> Exactly, that's why I want to see this "damn thing" nailed down.

same here.

> 
> Actually, I want
> * Silke to wake up and start cooperating
>  or 
> * some volunteer to take over her package
>  or
> * somebody closing this RR, giving others the liberty of resubmitting a new one.

like above id still say that there should be some rules nailed down.


> 
> > also e.g. in the case of initng ...
> initng and my other very friend elektra are completely different cases. IMO,
> these packages are a million miles away off from being ready for public use.

but theres fedora specific work to be done. the initng daemon is ready in the
next release probably because all buildwarnings been fixed and it also works on
x86_64 pretty well already.

the scripts have to be tweaked in a fedora special way at times so theres a good
point to start off the work.
i can see your point of view that this is development work... but thats life...
with a project like replacing the init system you cant just go there alone and
fix it up in a day. i think that the bugzilla thread helped alot in getting a
dedicated place to get the right things together to fix all open issues that
arise or are brought up in this and future release to block it from inclusion
into extras.
thats the point of a review. i use initng on 2 fedora boxes personally. a
thinkpad r51 and a x86_64 desktop box.
having the thread really fired up lots of work that might not have happened
without it. i wouldnt have looked at it either and also submitted a few small
patches upstream already.
> 
> In case of gdal the situation different: This simply is a case of a submitter
> being non-responsive for reasons I can only speculate on. 

yeah but in both cases my conclusion is the same. there needs to be a pinned
down rules what is supposed to happen and not. e.g. in this case asking for
someone to takeover i think is a better thing. like on the mailinglist.

elektra is again completly different because initng offers undoubtfully features
 certain interest groups are missing yet and theres no comparable other stab at
it currently.

elektra though is something that requires changes in alot other packages to be
useful.... unless... someone goes and makes bindings to all scripting languages
with swig. then people could just use it for some projects if they fill its
nice. its there anyways. some people are interested in it enough to maintain a
package.
I am also not yet sure though if it would be my taste

> 
> > hope you dont take the response as offensive.. its not meant to be.
> Understood.
> 
> 




Comment 28 Ralf Corsepius 2006-06-07 10:10:58 EDT
Closing, due to

https://www.redhat.com/archives/fedora-extras-list/2006-June/msg00275.html

Shaun, Rudolf or whoever feels addressed, feel encouraged to submit a new
versions of gdal for review.
Comment 29 Patrice Dumas 2006-08-08 12:28:15 EDT
Make that review block FE-DEADREVIEW
Comment 30 Ralf Corsepius 2006-08-09 01:13:10 EDT
(In reply to comment #29)
> Make that review block FE-DEADREVIEW

I fail to see the usefulness of FE-DEADREVIEW. All it does is to add further
bureaucracy.
Comment 31 Patrice Dumas 2006-08-09 04:08:42 EDT
If I understand well it is not something mandatory, it may
help contributors who want to submit a package, as in case
it has allready been submitted but abandonned they can see
it by looking at the FE-DEADREVIEW tree.

If it was mandatory sure it would add more bureaucracy.
Comment 32 Joost Soeterbroek 2006-09-10 15:16:39 EDT
New review request:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=205955
Comment 33 Mamoru TASAKA 2006-09-23 13:29:58 EDT
Marking this as duplicate as new request appeared.

*** This bug has been marked as a duplicate of 205955 ***

Note You need to log in before you can comment on or make changes to this bug.