Bug#1024883: Reconsider versioned dependencies of libpinyin-data
On 2022-11-27 20:00, Boyuan Yang wrote:
在 2022-11-27星期日的 13:31 +0100，Gunnar Hjalmarsson写道：
I take it that Sebastian talks about:
Depends: libpinyin-data (= ${binary:Version})
in libpinyin15 and libzhuyin15.
Question: Would it be an option to change those dependencies to not
be versioned in order to make future transitions easier, or are
there reasons for keeping it as it is?
It really depends on whether mismatched libpinyin library +
libpinyin-data will cause big troubles. If mismatched versions will
cause crash, the relaxed dependency should make no sense. Current
implementation is the most conservative one, yet it won't cause
obvious troubles.
I kind of hoped that somebody knows offhand. Otherwise the effort to
find out would probably not be worth it. After all, it's five years
since upstream last bumped the SONAME.
--
Gunnar
Bug#1024883: Reconsider versioned dependencies of libpinyin-data
X-Debbugs-CC: gunna...@debian.org
Hi,
在 2022-11-27星期日的 13:31 +0100，Gunnar Hjalmarsson写道：
> Package: src:libpinyin
> Version: 2.7.92-2
>
> Hi all!
>
> Upstream made a SONAME bumb:
>
> https://github.com/libpinyin/libpinyin/commit/2f52299e
>
> While I don't really understand the reason for it, the resulting
> paperwork in Debian is now done.
>
> At the transition bug we had this conversation:
>
> On 2022-11-26 15:44, Sebastian Ramacher wrote:
> > On 2022-11-25 14:52:12 +0100, Gunnar Hjalmarsson wrote:
> > > I notice that libpinyin has not yet migrated, even though the 2
> > > days delay is over. Is that because Britney waits for the
> > > dependencies to be migration ready too, or is it because this bug
> > > is not closed yet?
> >
> > It has not migrated yet because the shared library packages have
> > strictly versioned dependency on libpinyin-data. Hence, migrating
> > libpinyin to testing would currently render some packages
> > uninstallable in testing.
> >
> > Ideally, this dependency would be relaxed if possible so that this
> > won't be an issue for the next libpinyin transition. For this one,
> > all the reverse dependencies and libpinyin need to migrate together.
>
> I take it that Sebastian talks about:
>
> Depends: libpinyin-data (= ${binary:Version})
>
> in libpinyin15 and libzhuyin15.
>
> Question: Would it be an option to change those dependencies to not be
> versioned in order to make future transitions easier, or are there
> reasons for keeping it as it is?
It really depends on whether mismatched libpinyin library + libpinyin-data
will cause big troubles. If mismatched versions will cause crash, the
relaxed dependency should make no sense. Current implementation is the most
conservative one, yet it won't cause obvious troubles.
Thanks,
Boyuan Yang
signature.asc
Description: This is a digitally signed message part
Bug#1024883: Reconsider versioned dependencies of libpinyin-data
Package: src:libpinyin
Version: 2.7.92-2
Hi all!
Upstream made a SONAME bumb:
https://github.com/libpinyin/libpinyin/commit/2f52299e
While I don't really understand the reason for it, the resulting
paperwork in Debian is now done.
At the transition bug we had this conversation:
On 2022-11-26 15:44, Sebastian Ramacher wrote:
On 2022-11-25 14:52:12 +0100, Gunnar Hjalmarsson wrote:
I notice that libpinyin has not yet migrated, even though the 2
days delay is over. Is that because Britney waits for the
dependencies to be migration ready too, or is it because this bug
is not closed yet?
It has not migrated yet because the shared library packages have
strictly versioned dependency on libpinyin-data. Hence, migrating
libpinyin to testing would currently render some packages
uninstallable in testing.
Ideally, this dependency would be relaxed if possible so that this
won't be an issue for the next libpinyin transition. For this one,
all the reverse dependencies and libpinyin need to migrate together.
I take it that Sebastian talks about:
Depends: libpinyin-data (= ${binary:Version})
in libpinyin15 and libzhuyin15.
Question: Would it be an option to change those dependencies to not be
versioned in order to make future transitions easier, or are there
reasons for keeping it as it is?
--
Cheers,
Gunnar
