[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [SCM] liblas annotated tag, upstream/1.6.0, created. upstream/1.6.0



Hello people,

On Sat, 12 Feb 2011 17:10:42 +0000, David Paleino wrote:

> The following commit has been merged in the master branch:
> commit 09b04fc2c3bb1c75ffb9811b4ef33e00d12864c5
> Author: David Paleino <dapal@debian.org>
> Date:   Sat Feb 12 18:10:26 2011 +0100
> 
>     Add temporary note to changelog
> 
> diff --git a/debian/changelog b/debian/changelog
> index 7fdbbaf..c1a26a0 100644
> --- a/debian/changelog
> +++ b/debian/changelog
> @@ -1,5 +1,12 @@
>  python-liblas (1.6.0-1) UNRELEASED; urgency=low
>  
> +  ***DON'T UPLOAD***
> +  TODO: liblas transition should be handled first. Also,
> +        00-fix_library_search.patch should be checked, since
> +        maybe liblas 1.6.0 changed the library name to
> +        liblas_c.so.
> +  ******************
> +
>    * New upstream version
>    * Use "3.0 (quilt)" source format
>      - drop quilt from Build-Depends
> 

On Sat, 12 Feb 2011 17:25:44 +0000, David Paleino wrote:

> The annotated tag, upstream/1.6.0 has been created
>         at  d31c01a3149a5316bf3d39581a66ce2284cf1282 (tag)
>    tagging  999b3ef6f6f3eae79d6ed48915d1a14244fddf56 (commit)
>   replaces  upstream/1.2.1
>  tagged by  David Paleino
>         on  Sat Feb 12 18:22:15 2011 +0100
> 
> - Shortlog ------------------------------------------------------------
> Upstream version 1.6.0

Indeed, the SONAME is bumped.
1.6.0 builds liblas.so.2 and liblas_c.so.2 (and there are other differences,
such as cmake instead of autotools).

The only reverse-dependency is python-liblas. So there's not even need to
coordinate the transition with the RT.

However, 1.6.0 includes a python binding, which is identical to python-liblas
1.6.0. Better, it includes a testsuite and code examples.

libLAS 1.6.0 also includes C# bindings, which I believe worth building and
distributing in binary packages.

Here's my proposed plan:

 1. prepare liblas-1.6.0, with SONAME bumped (liblas2), and new binary packages
    (I still have to check the differences between liblas.so and liblas_c.so,
    and if they deserve separate packages)
 2. ask for removal of python-liblas
 3. upload liblas to NEW
 4. package gets ACCEPTED
 5. PROFIT.

There's no need of Conflicts, Breaks or such other things, as the version is
greater than the one currently in archive, so users will just see a new version
of the python-liblas binary package (and they don't care about the originating
source package).

Any comments?

Kindly,
David

-- 
 . ''`.   Debian developer | http://wiki.debian.org/DavidPaleino
 : :'  : Linuxer #334216 --|-- http://www.hanskalabs.net/
 `. `'`  GPG: 1392B174 ----|---- http://deb.li/dapal
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174

Attachment: signature.asc
Description: PGP signature


Reply to: