Re: gEDA-user: Debian gEDA update

[Magnus Danielson <cfmd@xxxxxxxxxxxx>]

From: Charles Lepple <clepple@xxxxxxxxx>
Subject: Re: gEDA-user: Debian gEDA update
Date: Sun, 13 Feb 2005 17:58:12 -0500
Message-ID: <af89664605021314584678ded8@xxxxxxxxxxxxxx>

Charles,

> On Sun, 13 Feb 2005 22:43:32 +0100, Iznogood
> <iznogood@xxxxxxxxxxxxxxxxxxxx> wrote:
> > The only "anomaly" is that gschem and the others asked for libgeda22
> > were satisfied by libgeda20 update but evrythink seems working fine.
> 
> That caught me off-guard as well, but note that the latest geda-*
> packages no longer request libgeda22. It should make sense after you
> read the latest entry in the packaging changelog
> (/usr/share/doc/libgeda20/changelog.Debian.gz):
> 
> libgeda (20041228-2) unstable; urgency=low
> 
>   * Revert library package name to libgeda20 from libgeda22.
>   * Change in debian library packaging strategy for gEDA.
> 
>     This strategy is designed to cope with regular SONAME changes better.
>     given that the application packages are a small set which are always
>     released at the same time as the library, and maintained by the
>     same developer.

This is a point I made and which is quite obvious in this case. libgeda isn't
used by any non-geda applications in Debian (or at all to the best of my
knowledge).

>     The application packages now depend on a virtual package called
>     libgeda-<soname>, which is provided by the library package.
>     When the library version changes, all dependent packages must
>     be rebuilt, which is standard practice anyway.
> 
>     Later, libgeda20 should be renamed to libgeda. This should all
>     avoid regular NEW processing delays due to library name changes.

This is also what I proposed. Keep libgeda20 for now, forget libgeda22 and
push libgeda in the pipe and when it arrives it replaces libgeda20. This way
the issue is resolved quickly and a propper fix is in the pipe but not really
stopping the use of the new geda packages.

>   * Added conflicts with existing versions of gEDA application packages
>     to force an upgrade to the new scheme. Otherwise, gEDA <= 20040111
>     would install with this libgeda20 but not run.

A maintainers necessary trick to keep things inline. We are thankfull that they
do this for us... when it works out like they thought it would. The libgedaXX
issue is an example when it does not work out as intended.

>   * Trimmed pre-woody libgeda versions from the Conflicts line.
> 
>  -- Hamish Moffatt <hamish@xxxxxxxxxx>  Sun, 13 Feb 2005 00:14:01 +1100

I emailed Hamish and asked him to do this or something similar in order to
solve the issue of the dangeling geda packages due to the huuuuge delay of
libgedaXX (where XX was 22 this time). However, it was like playing towards an
open goal, since Hamish was already considering doing something like this, but
my friendly kick in the but got him going and earlier today I was able to see
the solution.

Anyway, being a packet-maintainer brings in additional aspects to help confuse
the picture a little more. I am happy that I don't have to do all the work.

Thanks again Hamish!

Cheers,
Magnus