[Pkg-silc-devel] Updating SILC Toolkit to 1.0.2

[Daniel Kahn Gillmor]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri 2007-05-25 20:30:51 -0400, Jérémy Bobbio wrote:

> In my opinion, it would be better to switch directly to package 1.1
> beta 3.  Debian is currently in the "heavy development" phase, and
> it seems a good period for me to give upstream code a wider range of
> potential testers.

i think this is a good idea as well.

> Another possibility would be an upload of 1.0.2 to unstable, and an
> upload of 1.1 beta 3 to experimental.  It also depends on how different
> the packages would be on the Debian side.

this strikes me as more work than we need, and we've already got our
work cut out for us :/

> SILC Toolkit 1.1 beta 3 uses the libtool flag "-release 1.1".  Quoting
> dancer's guide:
>
> --- 8< ---
> 2. Choosing which method to use for versioning
>
> The upstream authors have the liberty of choosing two major methods for
> versioning using libtool. -version-info, and -release. -release is used
> for unstable libraries that change ABI on every new release. However,
> such unstable library package usually don't belong in Debian, because it
> will require a rebuild in every dependent package against the new
> library package.
>
> -release is recently used more for signifying major releases. Due to the
> serial nature of -version-info, SONAME version numbers usually get quite
> large fairly quickly. Using new -release value in major library release,
> the SONAME version numbers can be re-set to zero. Some people prefer the
> lower numbers. 
> --- >8 ---
>
> Upstream currently gives "-version-info 1:0:0 -release 1.1" to libtool.
> If I'm not mistaken, the new binary package should thus be named
> libsilc-1.1-1.

urg.  thinking about library versioning always makes my head hurt.
But i guess it's as good a time as any to really try to understand it,
finally.  I'm going to try to re-read dancers guide, and take notes.
Would the more-experienced folks on this list mind if i asked
questions about this stuff here?  i'm already learning a lot from you
guys.


> In any case we have to be careful about API or ABI breakage while
> 1.1 is still in beta.

Indeed!  Given upstream's semi-haphazard versioning scheme, i think
this is something we need to pay close attention to.

> Another aspect we need to consider is that we are going to make
> every package depending on libsilc-1.0-2 uninstallable right after
> the new upload.  We might want to check if the other packages build
> correctly with the new version, and if it won't be better to fix the
> one that doesn't before a more massive coordinated upload...

Fortunately (unfortunately?) there aren't currently many packages
depending on libsilc:

[0 dkg at squeak ~]$ apt-cache rdepends libsilc-1.0-2
libsilc-1.0-2
Reverse Depends:
  ggz-grubby
  silky
  libsilc-1.0-2-dev
  ggz-grubby
[0 dkg at squeak ~]$ 


i don't know why ggz-grubby shows up twice, but we should probably let
Debian GGZ Maintainers <pkg-ggz-maintainers at lists.alioth.debian.org>
know about our plans, so they're not surprised by all this.  It looks
like we control the other stuff ourselves.

This is another argument for jumping in fully to 1.1 now, actually.
less work for us doing the 1.0 -> 1.1 transition for silky and any
other dependencies we start to accumulate within debian.

   --dkg
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>

iD8DBQFGV4WFiXTlFKVLY2URAnihAKDGzEjDkYBLYAMJH/cZoXkDGQ3jEwCeO3zH
/fTz6nyJP1AggKJr10UtsVU=
=1TPQ
-----END PGP SIGNATURE-----