Re: Removal of postgis [was: List of remaining libraries for C++ transition]
hi friends,
postgis is a package providing a plugin for postgresql, hence the
library file(s) are located within the postgresql hierarchy, and are not
for general interest (as for linking to general c programs).
the soname changing significance is usually a change in the abi, and in
postgis there is also a very important meaning: change in the format of
the saving the gis data in the databases.
besides the c++ abi change, debian unstable and testing undergone a deep
change in the way postgresql is being handled, that meaning presence of
multiple postgresql versions on the same system. postgresql 7.4, once
the only one installed in sarge, became postgresql-7.4, and is living
side by side with postgresql-8.0, and newer.
the postgis package which is now candidate for removing was compatible
with the older one postgresql aproach, and is not working with the
present one, anyway. it has been submitted while sarge was testing, but
is living now in a totally incompatible environment (see the bug reports).
on the other hand, the new postgis0 and postgis1 packages are the only
to support the present multi postgresql environment, and the soname is
been used here to allow concomitent usage of databases holding gis data
in both formats, as stated above. nevertheless, the newer packages are
closing the bugs filed against the older one.
since the old postgis package is not working in present testing/
unstable, and it's not being distributed with woody/sarge, where it
could work, there is oficially no need for transition from the old
package to the new postgresql environment.
nevertheless, for woody/sarge users that might have installed the old
package, i have agreed with martin pitt, maintainer of postgresql, to
implement a general purpose transition path to all contributed
postgresql packages, even third party. this path will be automatically
run upon postgresql transition, most probably when a user upgrades to etch.
i hope that now our differences may be settled, so that postgis[01] will
get to general debian users, thus facilitating debian support of more
packages, that might use postgis.
best regards,
alex
Steve Langasek wrote:
> On Sun, Nov 27, 2005 at 10:54:08AM +0100, Giuseppe Sacco wrote:
>
>>Hi Steve,
>
>
>>Il giorno dom, 27/11/2005 alle 00.06 -0800, Steve Langasek ha scritto:
>>[...]
>>
>>>The postgis source package has already been removed from testing. In
>>>addition, the existing postgis source package is already libpostgis1; is
>>>there a good reason for renaming this source package?
>
>
>>Upstream release its source as 'postgis'. The maintainer would like to
>>provide a package for version 0.9.2 an a package for version 1.0.4.
>>He renamed the postgis-0.9.2 in 'postgis0' and postgis-1.0.4 in
>>'postigs1' and now he create many binary packages that keep a '0' or '1'
>>in their names.
>
>
> Yeah, that's not really a good reason to change the source package name.
> All it does is add to inconsistency across Debian versions; at least one
> ftpmaster (Anthony Towns) has argued that gratuitous source package name
> changes, as this one appears to be, are grounds for rejection.
>
>
>>I proposed to only change the name of 0.9.2 and keep 1.0.4 as postigs,
>>but the maintainer will was different. No special reason, i think. I am
>>putting him in bcc so he may provide more information.
>
>
> Ok.
>
>
>>>I guess the binary package has changed names from libpostgis1-pg74 to
>>>libpostgis1-pg7.4, and this covers us for the C++ ABI transition?
>
>
>>The binary package keep the same name since it already included the '1'.
>>The library name is liblwgeom.so.1 for 1.0.4 (no change) and
>>libpostgis.so.0 for 0.9.2 (new library).
>
>
> - this is not the same binary package name. One is pg74, the other is
> pg7.4.
> - the '1' has *nothing* to do with this thread, which is about dealing with
> the g++ ABI change.
> - the libpostgis1-pg74 package is either a badly-structured (and badly
> named) shared library package, or it's a badly-structured plugin package.
> I can't tell which very easily, because the packaging is sufficiently
> wrong. If this is a shared library package, the library should be in
> /usr/lib instead of /usr/lib/postgresql/lib/, there is a missing -dev
> package, and the package ought to be named liblwgeom1. If it's a plugin
> package, the use of an soname and shlibs is superfluous and misleading.
> And also would mean that no package rename is required.
>
>
>>There is probably no change for a real transition since the old package
>>had FTBFS bugs and hence it wasn't used that much. Some user where
>>subscribed to pkg-grass@alioth and already tested the new package and
>>developed an upgrade path.
>
>
> That's not really an acceptable rationale for not handling an ABI
> transition. If the package *exists*, the only reasonable assumption is that
> it has users; and those users deserve smooth transitions, because smooth
> transitions are part of what *makes* Debian an attractive system for users.
>
Reply to: