[postgis-users] Re: [DebianGIS] PostGIS status for debian unstable

[Stephen Frost]

* alex bodnaru (alexbodn at 012.net.il) wrote:
> i'm glad this thread emmerged to the debian gis list. all of us seek
> debian wealth, but part of us really need operable gis software, and are
>  using mixed debian installation (sometimes complemented with upstream
> code) in order to achieve it.

Sure, and I'm part of that group myself, though as a DD I tend to build
my own debs when I need them instead of just doing a 'make install'.

> one of those wonderful upstream sources is postgis, which is being
> supported for every postgresql since 7.2 (available and tested on
> woody). they also do support the original postgis 0.9 for all servers. i
> personnaly know of debian users of all those features.

Just because upstream supports every version since the dawn of time is
not a good reason to introduce every version into Debian.  They support
those versions because they want backwards compatibility.  That doesn't
make sense in Debian when there's no prior PostGIS package in Debian.
Indeed, as I mentioned, Debian will *never* have a release which
includes PostgreSQL 8.0.

> as an aim to serve this community, i've made a debian package able to
> build for any postgresql available on the builder's debian installation.
> the package i've uploaded on debian gis does really build and work on
> every debian since woody, with servers 7.2 and later, with either one or
> multiple clusters installed.

I appriciate this but I honestly think this could have been done without
the level of complication present in the current PostGIS build.
Additionally, it's not acceptable to Debian unless it can be compiled on
the Debian build daemons and that it compiles in a sane manner.
Unfortunately, the current PostGIS doesn't seem to do that so well.

> the relatively complex way to build the package made it subject to
> repetitive bounces from unstable, even though i've expressed my
> intention to fix all issues.

The issues have to be fixed *before* uploading to the NEW queue,
especially when the fixes would require another trip through the NEW
queue.  Additionally, packages aren't rejected because they have a
complex build system generally, as long as the build system is clean,
thought out, and builds the appropriate packages.

> this time i incline to think my package was bounced on grounds that
> existed before, but have been set as critical, but the dd that
> recommended the package rejection has done it comparing some features of
> the above described package to a package he submitted to new, instead. i
> will address the issues below:

While this is a cute swipe at me it doesn't make a whole lot of sense:
when I realized PostGIS was in the NEW queue (and already in Debian for
that matter), I immidiately asked for my package to be rejected (which
was done in quite short order, and was done prior to my comments about
your package).  This was also after a week had passed and the package
hadn't been admitted; if you'd like to check w/ Joerg you'll find that
he was already unhappy about the package because it was adding a
dependency on 8.0 (an issue I generally don't have a problem with but
understand why he does).  Feel free to check with Steve Langasek as
well.  Not to mention the various bug reports regarding the package in
the BTS and the discussion that happened prior to my involvment at all
on debian-release.

No, this isn't a turf war, it's about making sure we have the best
PostGIS package in Debian we can.  Believe me when I say that I really
want to get PostGIS in a *good* state in Debian.  I'm willing to spend
the effort to critique the packaging and help it get through the NEW
queue when it's ready.  I can assure you that trying to twist arms to
get it through the NEW queue isn't going to work. :)

> Stephen Frost wrote:
> > It's not in good shape, to say the least.  I've spoken with Alex about
> > this in the past and am trying to encourage him to fix the problems with
> > the new packaging.  At the very least:
> > 
> >   * The PostGIS module name should be postgresql-X.Y-postgis where X.Y
> >     corresponds to the PostgreSQL version.
> >   * The utilities shipped with PostGIS are not dependent on the version
> >     of PostgreSQL and therefore there should not be multiple binary
> >     packages for the utilities.
> 
> both those issues are reasonably important, and i've already started
> working on them.

Glad to hear it.

> >   * PostGIS should not be building packages for 8.0 or really for 7.4.
> >     8.0 is being phased out of Debian/unstable and will be gone prior to
> >     the etch release.  7.4 only remains so that a sane transistion can
> >     be done from sarge.  PostGIS doesn't exist in sarge and so there's
> >     no need for this.
> 
> during the long period between debian stable releases, postgresql
> released 8.0, now superseeded by 8.1. postgis deb will automatically
> build for the installed postgresql only. thus, the postgresql-8.0
> postgis will be built only where postgresql-8.0 exists.

The control file shouldn't be hacked up during the build process.
You're implying here that either it is or that packages will be built
which aren't in the control file, depending on the current state of the
system.  Neither of these are acceptable, sorry.  I appriciate your goal
of wanting to have the package build whatever packages it can but what
this does is cause problems for the build daemons and the security team.

> >   * PostGIS should not be including multiple different major versions of
> >     the PostGIS source code and shouldn't be building old major versions
> >     using the same source package.  This is essentially insane.  If we
> >     need multiple major versions of PostGIS in Debian then they should
> >     be built from different source packages (hint: We *don't* need, or
> >     want multiple major versions of PostGIS in Debian especially since 
> >     the it looks like the older version only works w/ 7.4 anyway)
> 
> i don't think the 0.9 issue is been correctly expressed here, but the
> 0.9 package is separated from 1.1 and is not an issue in this letter.

Odd, I saw it in the upload list to the NEW queue, which should have
meant that it had been built from the PostGIS source package also in the
NEW queue...

> >   * The build system for PostGIS absolutely sucks and causes problems
> >     for anyone else (build daemon or other) trying to rebuild it.  This
> >     results in FTBFS bugs which are release-critical.  No package with
> >     such issues should be uploaded to the archive.
> 
> could you please elaborate your explanation: what exactly does it suck,
> and what are the current problems your are talking about?

The issues above are some of the current problems but I'll happily go
through the issues in more detail.

> > The PostGIS package was rejected (aiui) due to #2 and #3 above but I
> > don't believe fixing just those would allow it to get through or would
> > be in anyone's best interest.  I've packaged PostGIS myself using CDBS
> > for 8.1 and it went quite decently and works pretty well.  I'm happy
> > enough if Alex fixes the issues with the packaging though.
> 
> thanks for your infinite generosity.

I appriciate the sarcasm, however, don't expect me to let up because
you've decided that I'm somehow the enemy here.  PostGIS *and* Debian
are important to me and I'm not going to sacrifice one for the other.  A
maintainer needs to work *with* Debian, not against it.

	Thanks,

		Stephen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20060201/f4499be2/attachment.pgp>