[Pkg-ime-devel] Bug#750623: Bug#750623: Bug#750623: What is the hold-up of uploadin new package

[Guo Yixuan]

Hi,

On Mon, Jun 23, 2014 at 8:03 AM, Osamu Aoki <osamu_aoki_home at nifty.com>
wrote:
> On Sun, Jun 22, 2014 at 12:01:49PM -0400, GUO Yixuan wrote:
> > On Sun, Jun 22, 2014 at 08:27:12PM +0900, Osamu Aoki wrote:
> > >
> > > On Sun, Jun 22, 2014 at 01:45:32AM +0800, Aron Xu wrote:
> > > > On Sun, Jun 22, 2014 at 1:33 AM, GUO Yixuan <culu.gyx at gmail.com>
wrote:
> > > > > I'm just waiting for a confirmation on the librime-dev =>
librime1-dev
> > > > > renaming, from Aron, as we discussed in a previous thread. [1]
> > > > >
> > > >
> > > > As said before, I don't have strong opinion on either way.
> > >
> > > My popsition is that you have not presented enough reason to do this.
> > > So do not do this.
> >
> > I remember one possible reason: librime 1.0 breaks some ABI and API
> > compatibility,
>
> Yes.  Thus you need to change librime0 to librime1 etc.
>
> > so we should change the -dev package name. [1][2]
>
> No.  Your reference does not say so.
>
> This is only needed if you are having massive dependency and transition
> library in complicated arrangement which you seem not to chase.
>
> KISS (Keep it simple and S***) is the reason why I said no.  (I am not
> saying your method break things)
>
> As long as all dependency packages are binNMUed using the standard
> procedure, the same librime-dev is sufficient and simple.
>
> Let's review what your reference say:
>
> > [1] https://wiki.debian.org/TransitionBestPractices
>
> The first reminder is:
>
> If there's a backward-incompatible ABI change (binary incompatibility)
> which prevents old programs from working with the new library: you need
> to change the library soname, and you need to change the library package
> name, but you usually should not change the -dev package name.
>               ^^^^^^^^^^^^^^^^^^^^^^^^^
>
> > [2]
http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#sonameapiabi
> Hmmm... not therer but look at:
>
http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#id249952
>
> 1. -DEV package names
>
> Package maintainer has two options when naming a shared library -DEV
> package.
> ...  This document is neutral on which method to deploy.
>
> You did not present rationale to do extrastep with the second option.

There seems to be something more than ABI break.
librime 1.0 modified several struct member definitions, eg., in the
definition of RimeMenu in include/rime_api.h. Is it an API break?
If yes, then we should rename, in my opinion. (By the way, other
source code imcompatibilities may exist, as indicated in the
ChangeLog, "while source code compatibility is largely
maintained with the exception ...")

quote from [2]
> If it only requires a source rebuild, it is called a ABI breakage.
> When even a rebuild is not enough, and there is a source-level
> change required for applications to work with the new version
> of the library, it is called a API breakage, and a different -DEV
> package name should be chosen for the new version of the
> shared library package.

[2]
http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#sonameapiabi

>
> I see
> librime1 (>= ${source:Version}), librime1 (<< ${source:Version}+1~)
>
> This seems binNMU unsafe.  Please drop max version limitation.


Dropped as in c84e9eb.

http://anonscm.debian.org/gitweb/?p=pkg-ime/librime.git;a=commitdiff;h=c84e9eb4e31887ab68df7fbbe4599bfed753a27a;hp=5c651d8d3974b95a8592f1bb8fec05f0bf419d70

Regards,

Yixuan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-ime-devel/attachments/20140629/925b6d4f/attachment-0001.html>