[Pkg-electronics-devel] gEDA 1.6.0 packages (and packaging)

[Hamish Moffatt]

On Thu, Nov 19, 2009 at 08:32:41PM +0200, أحمد المحمودي wrote:
> On Wed, Nov 18, 2009 at 04:02:49PM +0000, Peter Clifton wrote:
> > > 2) Why is the locale of libgeda installed in libgeda38 instead of 
> > > libgeda-common ?
> > 
> > I'm not 100% sure, but I think the reasoning is along these lines....
> > the locale "domain"(?) for lingeda38 _is_ "libgeda38".
> > 
> > It is not common to different libgeda versions - thus it is no defferent
> > to a lib* installing its locale files. libgeda-common was created
> > because the libgeda package installs some non-version-specific files.
> > 
> > In general, the fact that Debian split libgeda such that it can
> > (hopefully) co-exist with other libgeda soversions on the same machine
> > is probably a little overkill (since all geda pakages come from the same
> > source, and are updated at the same time) - although it isn't a problem.
> 
> Hamish: can you help regarding this question ?

I don't think there are good reasons in practice to have libgeda
versioned as we do. It's Debian policy though and theoretically it makes
dpkg/apt's job a bit easier - there is less coupling between libgeda*
and the applications so upgrade ordering is less critical.

In practice, libgedaXX is bound to a specific version of libgeda-common
due to the scheme sources etc, so you can't really install multiple
versions, and all the advantages disappear.

For quite a while we had libgeda22 containing libgeda >> 22, and a
virtual package libgeda-22, -23 etc specifying the real version. This
wasn't policy compliant though and eventually I was forced to stop.

> Hamish, I also need help regarding the following:
> 
> 1) Peter did the following change in calling dh_makeshlibs:
> 
>   Fix dependancy of >= $UPSTREAM_VERSION to match the exact debian 
>   version of libgeda which was built with this source package.
> 
>   I was talking with Peter today, and he said about this:
> 
>   "Something did seem wrong with the resulting packages though - as it
>   required a dist-upgrade to remove the old version of libgeda, and for
>   the new install to proceed Presumably the old version of
>   libgeda-common should be replaced successfully with a new
>   libgeda-common, the old libgeda33 or whatever should remain until the
>   old geda-* are replaced - at which point libgeda33, unused..  is
>   removed"

It's safest to have an exact match between all the packages, though
sometimes more strict than necessary. That doesn't stop you installing a
newer libgeda than the applications though. For libgeda-common we do
this with

Depends: libgeda-common (>= ${source:Version}), libgeda-common (<< ${source:Version}.1~), ...

I don't know if you can do this with dh_makeshlibs though.

> 2) geda-gaf is actually based on your work on the different geda-* 
>    packages, so how to mention that (both in copyright & changelog 
>    files) ?

Does the new source package continue the changelog from one of the old
packages, or is it brand new?


Hamish