Re: GNUstep libraries soname bump
[ Let's drop -release in subsequent follow-ups, unless the Release
Team has objections and/or someone wants to comment on this.]
At Mon, 09 Mar 2009 07:52:50 +0100,
Gürkan Sengün wrote:
> Yavor Doganov wrote:
> > Adeodato Simó wrote:
> > You are right that it doesn't depend on the GNUstep core libraries,
> > but it should.
> >> Or do you know more about this than the Packages.gz files do? :-)
> > The other packages in this situation are gnustep-netclasses and
> > pantomime1.2.
> likewise with renaissance (zipper.app)
OK, I'll take a look.
> and gorm.app (and gnustep-dl2)
At first glance, the problem here is far more severe. gorm.app should
ship its public shared libraries as separate binary packages and the
private ones should be installed under /usr/lib/gorm.app.
Likewise, gnustep-dl2 should ship the binary package dbmodeller.app
plus eventually the tools, if they're useful elsewhere. The
gnustep-dl2 source package should Build-Depend on the shared Gorm
public libraries, and not on gorm.app. Additionally, we have to
decide what to do with gnustep-dl2's own (gazillion) libraries, i.e.:
- ship a few libeo* binary packages containing them in /usr/lib
for the benefit of the Debian users building and deployoing
GNUstepWeb (please correct me if I'm wrong; I think this is the
only reverse dependency);
- ship them under /usr/lib/gnustep-dl2 as part of the
- ship them under /usr/lib/gnustep-dl2 but be prepared to move
them to /usr/lib when GSWeb is ready for inclusion in Debian.
All of this will be done after the forthcoming GNUstep transition as
uploads will be stuck in NEW. Undoubtedly it is a gross violation,
but not a practical problem as with the rest of the libraries. In
their current shape, both gorm.app and gnustep-dl2 depend on Base/GUI,
so they'll migrate together. We should not release them as they are
in Squeeze, though.