[Pkg-ime-devel] renamed to librime1-dev

[Guo Yixuan]

Hi,

Thank you for this detailed reply!

On Mon, May 12, 2014 at 8:50 AM, Osamu Aoki <osamu at debian.org> wrote:
>
> Hi,
>
> I am no expert on this topic but let me try my best and also share this
> with other DDs for pkg-ime.
>
> On Sun, May 11, 2014 at 07:35:06PM -0400, Guo Yixuan wrote:
> ...
> > I just have a question: in the so-version bump of librime,
>
> It was done by aron in git repo with pre-release version: librime0 ->
librime1
>
> Read basics here:
>
https://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-updates
>
> Since this is C++ based library, symbols support can be skipped.
>
> > librime-dev is renamed to librime1-dev,
>
> So you wanted to do this slightly different from what Aron did.  This is
> certainly OK to do this.
>
> Versioned -dev package can be made but unless you plan to keep both
> librime0 and librime1 in the same archive and build-able.  I do not see
> much reason to make this extra complication.

Yes, we don't seem to have enough motivation for versioned -dev package
name. Therefore, I was considering to revert to versionless -dev package
name.

> Anyway, rules are here:
>
https://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-dev
>
> (If you really wish to have both ABI packages in the archive, you need
> to have source package to be versioned to keep them happy. This kind of
> situation exist only for some select class of libraries.   Otherwise,
> your action only buys you to have minor future flexibility, as I
> understand.)

I don't think we have any reason to keep multiple version of source
packages here.

> Considering small numbers of programs depending on librime* library, I
> would rather keep it simple by having librime-dev for all so name
> versions as Aron.  I explained this case in my maint-guide:
>  https://www.debian.org/doc/manuals/maint-guide/advanced.en.html#library
>  https://www.debian.org/doc/manuals/maint-guide/advanced.en.html#multiarch

Yes, this is reasonable.

> > so I think it's necessary to add conflicts/replaces/provides[1].
>
> This ensures only one package providing librime-dev is installed.
> So good for your plan.
>
> > Is this the usual and correct way of  handling a so-version bump?
>
> Important is that this upload induced library transition.
> Please read https://wiki.debian.org/Teams/ReleaseTeam/Transitions
> and follow.
>
> You need to send mail to debian-release at lists.debian.org using reportbug
> with proper ben file.
>
> The example mail as follows in the basic transition mail example is for
> packaging style using librime-dev like -dev package.
>  https://lists.debian.org/debian-release/2012/02/msg00088.html
> Example of transition.
>  https://release.debian.org/transitions/html/libgpac3.html
>
> If you create versioned -dev package like you proposed, library
> transition comes with extra-flexibility.  If you see
> https://release.debian.org/transitions/ , transitions marked with auto-*
> are ones with versioned -dev packages.  Example transition.
> https://release.debian.org/transitions/html/auto-sword.html Anyway, I am
> not so familiar with auto transition thing.  That is required for major
> library.  You may need to get some external help (debian-mentor?) if you
> wish to go along this route.
>
> Good luck,
>
> Osamu
>
> > [1]
> >
http://anonscm.debian.org/gitweb/?p=pkg-ime/librime.git;a=commitdiff;h=462d9a54b1491e5e340d110fdde027834c6bc127

So, as I understand, versioned -dev (librime1-dev) has only one benefit of
automatic transition, while the versionless approach is more easy and
suitable for small-scale libraries (such as our librime). (I also have
little experience in shared libs however...) Let's wait a moment to see
Aron's comment on this issue.

(By the way, I encountered an annoying problem of librime 1.1, and am
debugging/trying to work with the upstream. Thus I think it's not necessary
to upload it right now.)

Cheers,

GUO Yixuan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-ime-devel/attachments/20140514/807a1cc8/attachment.html>