New libthai and pango

[Theppitak Karoonboonyanan]

Hi,

I have just uploaded a new upstream version of libthai (0.1.10-1) to
experimental. This new version now depends on libdatrie1 instead of
libdatrie0 as the implementation layer. But libthai itself still uses the old
APIs.

As a result, the soname for libthai is still the same, but that of libdatrie
is bumped up from 0 to 1.

As the shlib dependency is transitive, the pango-thai-lang.so module
is currently linked against libdatrie0. So, upgrading libthai would cause
both libdatrie versions to be loaded simultaneously, one from
pango-thai-lang.so itself, and the other from the new libthai.
Unfortunately, due to ABI incompatibility, some libdatrie functions
would not work correctly in that case.

So, pango would need to be rebuilt against the new libthai-dev
to fix the problem.

My question is, what should be the proper time for me to upload
the new libthai into unstable, to minimize down time for the pango
module? If I do that too soon, the pango module in unstable would
not work properly, or might even crash.

P.S. This may also apply to other libthai rdepends, like m17n-lib,
mlterm, and iceowl, as well. But I think pango is the most critical
one.

Thanks,
--
Theppitak Karoonboonyanan
http://linux.thai.net/~thep/


--
To UNSUBSCRIBE, email to debian-gtk-gnome-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Josselin Mouette]

Le lundi 30 mars 2009 à 20:22 +0700, Theppitak Karoonboonyanan a écrit :
> As the shlib dependency is transitive, the pango-thai-lang.so module
> is currently linked against libdatrie0. So, upgrading libthai would cause
> both libdatrie versions to be loaded simultaneously, one from
> pango-thai-lang.so itself, and the other from the new libthai.
> Unfortunately, due to ABI incompatibility, some libdatrie functions
> would not work correctly in that case.

And you wonder why we insist on symbols needing to be versioned in
libraries. Now there is no way to enforce the package will work using
usual dependencies.

Given the small number of reverse dependencies, it might be good to add
a conflict against libdatrie0 in the new version of libthai, to
completely avoid this issue.

> My question is, what should be the proper time for me to upload
> the new libthai into unstable, to minimize down time for the pango
> module? If I do that too soon, the pango module in unstable would
> not work properly, or might even crash.

Please synchronize with the release team to get it at the right moment,
since it implies a library transition. I’d appreciate if it could come
after the big gnome-desktop/nautilus transition that still has to be
done.

Cheers,
--
 .''`.      Debian 5.0 "Lenny" has been released!
: :' :
`. `'   Last night, Darth Vader came down from planet Vulcan and told
  `-    me that if you don't install Lenny, he'd melt your brain.

[Theppitak Karoonboonyanan]

2009/3/30 Josselin Mouette <joss@...>:

> And you wonder why we insist on symbols needing to be versioned in
> libraries. Now there is no way to enforce the package will work using
> usual dependencies.

Yes, with upstream's hat on, I realize that now, although a bit late..

> Given the small number of reverse dependencies, it might be good to add
> a conflict against libdatrie0 in the new version of libthai, to
> completely avoid this issue.

Ah, I also had that idea in mind for the next update, but didn't finalize
the thought on its appropriateness yet. Thanks for the suggestion.

> Please synchronize with the release team to get it at the right moment,
> since it implies a library transition. I’d appreciate if it could come
> after the big gnome-desktop/nautilus transition that still has to be
> done.

Could it be done along with the next pango update? That is, next
pango experimental build can link against it, and be tested before
migrating to unstable together. How is that possible?

FYI, I've tested it for a while in my jhbuild before releasing.

Regards,
--
Theppitak Karoonboonyanan
http://linux.thai.net/~thep/


--
To UNSUBSCRIBE, email to debian-gtk-gnome-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Josselin Mouette]

Le lundi 30 mars 2009 à 21:34 +0700, Theppitak Karoonboonyanan a écrit :
> 2009/3/30 Josselin Mouette <joss@...>:
>
> > And you wonder why we insist on symbols needing to be versioned in
> > libraries. Now there is no way to enforce the package will work using
> > usual dependencies.
>
> Yes, with upstream's hat on, I realize that now, although a bit late..

Then please consider adding them now, so that it can be smoother next
time :)

> Could it be done along with the next pango update? That is, next
> pango experimental build can link against it, and be tested before
> migrating to unstable together. How is that possible?
>
> FYI, I've tested it for a while in my jhbuild before releasing.

There is no real need to synchronize with pango, since the release team
can use binNMUs to rebuild all reverse-dependencies when needed.

Cheers,
--
 .''`.      Debian 5.0 "Lenny" has been released!
: :' :
`. `'   Last night, Darth Vader came down from planet Vulcan and told
  `-    me that if you don't install Lenny, he'd melt your brain.

[Loïc Minier-3]

On Mon, Mar 30, 2009, Theppitak Karoonboonyanan wrote:
> As the shlib dependency is transitive, the pango-thai-lang.so module
> is currently linked against libdatrie0. So, upgrading libthai would cause
> both libdatrie versions to be loaded simultaneously, one from
> pango-thai-lang.so itself, and the other from the new libthai.
> Unfortunately, due to ABI incompatibility, some libdatrie functions
> would not work correctly in that case.

 Why do you expose -ldatrie in pkg-config --libs libthai?  It seems to
 me pango doesn't use any of libdatrie's symbols and would work with
 either the new or the old libthai (that is would work with whatever
 version of libdatrie is used by libthai).

> So, pango would need to be rebuilt against the new libthai-dev
> to fix the problem.

 Could you change "Requires: datrie" to "Requires.private: datrie" in
 libthai.pc in unstable first?  We could then rebuild pango against
 this libthai.pc and drop the libdatrie dep hence avoiding the problem
 and the transition entirely (the binaries could migrate to testing
 separately).

--
Loïc Minier


--
To UNSUBSCRIBE, email to debian-gtk-gnome-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Theppitak Karoonboonyanan]

2009/3/30 Josselin Mouette <joss@...>:

> Le lundi 30 mars 2009 à 21:34 +0700, Theppitak Karoonboonyanan a écrit :
>> 2009/3/30 Josselin Mouette <joss@...>:
>>
>> > And you wonder why we insist on symbols needing to be versioned in
>> > libraries. Now there is no way to enforce the package will work using
>> > usual dependencies.
>>
>> Yes, with upstream's hat on, I realize that now, although a bit late..
>
> Then please consider adding them now, so that it can be smoother next
> time :)

I agree. I think I'll skip datrie 0.2.0 to a next bug fix release with
that added.

>> Could it be done along with the next pango update? That is, next
>> pango experimental build can link against it, and be tested before
>> migrating to unstable together. How is that possible?
>>
>> FYI, I've tested it for a while in my jhbuild before releasing.
>
> There is no real need to synchronize with pango, since the release team
> can use binNMUs to rebuild all reverse-dependencies when needed.

I see. So, I'll follow this when migrating libthai to unstable.

Regards,
--
Theppitak Karoonboonyanan
http://linux.thai.net/~thep/


--
To UNSUBSCRIBE, email to debian-gtk-gnome-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Theppitak Karoonboonyanan]

On Mon, Mar 30, 2009 at 11:26 PM, Loïc Minier <lool@...> wrote:

>  Why do you expose -ldatrie in pkg-config --libs libthai?  It seems to
>  me pango doesn't use any of libdatrie's symbols and would work with
>  either the new or the old libthai (that is would work with whatever
>  version of libdatrie is used by libthai).

I misunderstood something about link flags. Yes, -ldatrie is not needed
to be exposed indeed.

>  Could you change "Requires: datrie" to "Requires.private: datrie" in
>  libthai.pc in unstable first?  We could then rebuild pango against
>  this libthai.pc and drop the libdatrie dep hence avoiding the problem
>  and the transition entirely (the binaries could migrate to testing
>  separately).

OK. I'll do that soon. Thanks for pointing out.

Regards,
--
Theppitak Karoonboonyanan
http://linux.thai.net/~thep/


--
To UNSUBSCRIBE, email to debian-gtk-gnome-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Theppitak Karoonboonyanan]

On Tue, Mar 31, 2009 at 11:06 AM, Theppitak Karoonboonyanan
<thep@...> wrote:
> On Mon, Mar 30, 2009 at 11:26 PM, Loïc Minier <lool@...> wrote:

>>  Could you change "Requires: datrie" to "Requires.private: datrie" in
>>  libthai.pc in unstable first?  We could then rebuild pango against
>>  this libthai.pc and drop the libdatrie dep hence avoiding the problem
>>  and the transition entirely (the binaries could migrate to testing
>>  separately).
>
> OK. I'll do that soon. Thanks for pointing out.

0.1.9-5 uploaded to unstable.

Regards,
--
Theppitak Karoonboonyanan
http://linux.thai.net/~thep/


--
To UNSUBSCRIBE, email to debian-gtk-gnome-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Josselin Mouette]

Le lundi 30 mars 2009 à 18:26 +0200, Loïc Minier a écrit :
>  Could you change "Requires: datrie" to "Requires.private: datrie" in
>  libthai.pc in unstable first?  We could then rebuild pango against
>  this libthai.pc and drop the libdatrie dep hence avoiding the problem
>  and the transition entirely (the binaries could migrate to testing
>  separately).

Unfortunately this won’t work for upgrades from lenny, so I’d prefer to
see the Conflicts anyway.

--
 .''`.      Debian 5.0 "Lenny" has been released!
: :' :
`. `'   Last night, Darth Vader came down from planet Vulcan and told
  `-    me that if you don't install Lenny, he'd melt your brain.

[Theppitak Karoonboonyanan]

2009/3/31 Josselin Mouette <joss@...>:
> Le lundi 30 mars 2009 à 18:26 +0200, Loïc Minier a écrit :
>>  Could you change "Requires: datrie" to "Requires.private: datrie" in
>>  libthai.pc in unstable first?  We could then rebuild pango against
>>  this libthai.pc and drop the libdatrie dep hence avoiding the problem
>>  and the transition entirely (the binaries could migrate to testing
>>  separately).
>
> Unfortunately this won’t work for upgrades from lenny, so I’d prefer to
> see the Conflicts anyway.

You meaned partial upgrade with only libthai upgraded?
I still think the upgrade would work if pango were rebuilt with -ldatrie
removed, i.e., no more libdatrie0 should be directly loaded, except from
libthai0. Correct me if I'm wrong.

BTW, my current plan is, step by step:

1. Pango unstable be rebuilt with -ldatrie removed, to avoid possible down
time during libthai migration to unstable.

2. In experimental, try to solve the clash by adding symbol versioning
to libdatrie1. If not successful, add Conflicts on libdatrie0 to libthai0.
Meanwhile, libthai.pc in experimental is also updated like what's done
in unstable.

3. Migrate the libthai set to unstable, with binNMU coordination via the
release team.

Regards,
--
Theppitak Karoonboonyanan
http://linux.thai.net/~thep/


--
To UNSUBSCRIBE, email to debian-gtk-gnome-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Theppitak Karoonboonyanan]

On Tue, Mar 31, 2009 at 3:47 PM, Theppitak Karoonboonyanan
<thep@...> wrote:

> 2009/3/31 Josselin Mouette <joss@...>:
>> Le lundi 30 mars 2009 à 18:26 +0200, Loïc Minier a écrit :
>>>  Could you change "Requires: datrie" to "Requires.private: datrie" in
>>>  libthai.pc in unstable first?  We could then rebuild pango against
>>>  this libthai.pc and drop the libdatrie dep hence avoiding the problem
>>>  and the transition entirely (the binaries could migrate to testing
>>>  separately).
>>
>> Unfortunately this won’t work for upgrades from lenny, so I’d prefer to
>> see the Conflicts anyway.
>
> You meaned partial upgrade with only libthai upgraded?

(I forgot to insert "Otherwise," here.)

> I still think the upgrade would work if pango were rebuilt with -ldatrie
> removed, i.e., no more libdatrie0 should be directly loaded, except from
> libthai0. Correct me if I'm wrong.

--
Theppitak Karoonboonyanan
http://linux.thai.net/~thep/


--
To UNSUBSCRIBE, email to debian-gtk-gnome-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Josselin Mouette]

Theppitak Karoonboonyanan writes:
>> Unfortunately this won’t work for upgrades from lenny, so I’d prefer to
>> see the Conflicts anyway.
>
> You meaned partial upgrade with only libthai upgraded?
> I still think the upgrade would work if pango were rebuilt with -ldatrie
> removed, i.e., no more libdatrie0 should be directly loaded, except from
> libthai0. Correct me if I'm wrong.

If you upgrade only libthai, it will bring libdatrie1 while pango still
links to libdatrie0, so both libraries will be in the namespace.

However, thinking about it again, if you add symbol versions in libdatrie1,
this should work. Since pango doesn't actually use any symbols from
libdatrie, all required symbols will be required with a version, so the
correct ones will be selected.


--
To UNSUBSCRIBE, email to debian-gtk-gnome-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Theppitak Karoonboonyanan]

On Tue, Mar 31, 2009 at 4:56 PM, Josselin Mouette <joss@...> wrote:

> Theppitak Karoonboonyanan writes:
>>>
>>> Unfortunately this won’t work for upgrades from lenny, so I’d prefer to
>>> see the Conflicts anyway.
>>
>> You meaned partial upgrade with only libthai upgraded?
>> I still think the upgrade would work if pango were rebuilt with -ldatrie
>> removed, i.e., no more libdatrie0 should be directly loaded, except from
>> libthai0. Correct me if I'm wrong.
>
> If you upgrade only libthai, it will bring libdatrie1 while pango still
> links to libdatrie0, so both libraries will be in the namespace.

Yes, so you meaned the partial upgrade case, not when
pango is also rebuilt and upgraded as Loic proposed.

> However, thinking about it again, if you add symbol versions in libdatrie1,
> this should work. Since pango doesn't actually use any symbols from
> libdatrie, all required symbols will be required with a version, so the
> correct ones will be selected.

I suppose so. However, I've tried it and found no luck so far.
For the experiment, I've used "-Wl,--version-script=libdatrie.map"
LDFLAG instead of libtool -export-symbols flag, and list all
currently exported symbols under DATRIE_0.2 { global: ...; };
(with a "local: *" catch all in it, of course). Then I rebuilt both
libdatrie and libthai.

Here is what I got:

$ objdump -T /usr/local/lib/libdatrie.so.1.0.0

/usr/local/lib/libdatrie.so.1.0.0:     file format elf64-x86-64

DYNAMIC SYMBOL TABLE:
0000000000000c90 l    d  .init  0000000000000000              .init
0000000000000000      DF *UND*  0000000000000000  GLIBC_2.2.5 ftell
0000000000000000  w   D  *UND*  0000000000000000              __gmon_start__
0000000000000000  w   D  *UND*  0000000000000000
_Jv_RegisterClasses
0000000000000000      DF *UND*  0000000000000000  GLIBC_2.2.5 fseek
0000000000000000      DF *UND*  0000000000000000  GLIBC_2.2.5 __assert_fail
0000000000000000      DF *UND*  0000000000000000  GLIBC_2.2.5 malloc
0000000000000000      DF *UND*  0000000000000000  GLIBC_2.2.5 fopen
0000000000000000      DF *UND*  0000000000000000  GLIBC_2.2.5 __strdup
0000000000000000      DF *UND*  0000000000000000  GLIBC_2.2.5 free
0000000000000000      DF *UND*  0000000000000000  GLIBC_2.2.5 strlen
0000000000000000  w   DF *UND*  0000000000000000  GLIBC_2.2.5 __cxa_finalize
0000000000000000      DF *UND*  0000000000000000  GLIBC_2.2.5 sprintf
0000000000000000      DF *UND*  0000000000000000  GLIBC_2.2.5 memmove
0000000000000000      DF *UND*  0000000000000000  GLIBC_2.2.5 fread
0000000000000000      DF *UND*  0000000000000000  GLIBC_2.2.5 fclose
0000000000000000      DF *UND*  0000000000000000  GLIBC_2.2.5 fwrite
0000000000000000      DF *UND*  0000000000000000  GLIBC_2.2.5 realloc
00000000000028a0 g    DF .text  0000000000000005  DATRIE_0.2  trie_state_free
00000000000027a0 g    DF .text  00000000000000fb  DATRIE_0.2  trie_retrieve
0000000000002c30 g    DF .text  0000000000000255  DATRIE_0.2  trie_store
00000000000032a0 g    DF .text  0000000000000036  DATRIE_0.2  alpha_map_free
0000000000002640 g    DF .text  000000000000001f  DATRIE_0.2
trie_state_get_data
0000000000003000 g    DF .text  000000000000009e  DATRIE_0.2  trie_new
0000000000002960 g    DF .text  000000000000002a  DATRIE_0.2  trie_enumerate
00000000000032e0 g    DF .text  0000000000000222  DATRIE_0.2
alpha_map_add_range
0000000000002aa0 g    DF .text  00000000000000ff  DATRIE_0.2  trie_delete
0000000000002f40 g    DF .text  00000000000000be  DATRIE_0.2  trie_new_from_fil
0000000000002f10 g    DF .text  0000000000000027  DATRIE_0.2  trie_free
0000000000002610 g    DF .text  000000000000001d  DATRIE_0.2  trie_state_copy
00000000000030a0 g    DF .text  0000000000000026  DATRIE_0.2  alpha_char_strlen
00000000000028b0 g    DF .text  0000000000000060  DATRIE_0.2  trie_state_clone
0000000000002e90 g    DF .text  000000000000007e  DATRIE_0.2  trie_save
0000000000002780 g    DF .text  000000000000001b  DATRIE_0.2  trie_state_rewind
0000000000002630 g    DF .text  0000000000000005  DATRIE_0.2
trie_state_is_single
0000000000000000 g    DO *ABS*  0000000000000000  DATRIE_0.2  DATRIE_0.2
0000000000002660 g    DF .text  000000000000007a  DATRIE_0.2
trie_state_is_walkable
0000000000002910 g    DF .text  000000000000004c  DATRIE_0.2  trie_root
0000000000003510 g    DF .text  000000000000005c  DATRIE_0.2  alpha_map_clone
0000000000002600 g    DF .text  0000000000000004  DATRIE_0.2  trie_is_dirty
0000000000003280 g    DF .text  000000000000001f  DATRIE_0.2  alpha_map_new
00000000000026e0 g    DF .text  0000000000000095  DATRIE_0.2  trie_state_walk

$ objdump -T /usr/local/lib/libthai.so.0.1.2 | grep UND
0000000000000000      DF *UND*  0000000000000000  DATRIE_0.2
trie_state_is_single
0000000000000000      DF *UND*  0000000000000000  GLIBC_2.2.5 wcsncat
0000000000000000      DF *UND*  0000000000000000  GLIBC_2.2.5 snprintf
0000000000000000      DF *UND*  0000000000000000  GLIBC_2.2.5 wcsncpy
0000000000000000      DF *UND*  0000000000000000  GLIBC_2.2.5 wcslen
0000000000000000  w   D  *UND*  0000000000000000              __gmon_start__
0000000000000000  w   D  *UND*  0000000000000000
_Jv_RegisterClasses
0000000000000000      DF *UND*  0000000000000000  GLIBC_2.2.5 malloc
0000000000000000      DF *UND*  0000000000000000  DATRIE_0.2  trie_state_walk
0000000000000000      DF *UND*  0000000000000000  DATRIE_0.2  trie_state_free
0000000000000000      DF *UND*  0000000000000000  DATRIE_0.2  trie_state_rewind
0000000000000000      DF *UND*  0000000000000000  DATRIE_0.2  trie_state_copy
0000000000000000      DF *UND*  0000000000000000  GLIBC_2.2.5 free
0000000000000000      DF *UND*  0000000000000000  GLIBC_2.2.5 strlen
0000000000000000  w   DF *UND*  0000000000000000  GLIBC_2.2.5 __cxa_finalize
0000000000000000      DF *UND*  0000000000000000  DATRIE_0.2  trie_state_clone
0000000000000000      DF *UND*  0000000000000000  DATRIE_0.2  trie_new_from_file
0000000000000000      DF *UND*  0000000000000000  GLIBC_2.2.5 memcpy
0000000000000000      DF *UND*  0000000000000000  GLIBC_2.2.5 strchr
0000000000000000      DF *UND*  0000000000000000  GLIBC_2.2.5 getenv
0000000000000000      DF *UND*  0000000000000000  DATRIE_0.2  trie_root
0000000000000000      DF *UND*  0000000000000000  GLIBC_2.2.5 strcpy
0000000000000000      DF *UND*  0000000000000000  GLIBC_2.2.5 wcscat
0000000000000000      DF *UND*  0000000000000000  DATRIE_0.2  trie_free
0000000000000000      DF *UND*  0000000000000000  GLIBC_2.2.5 realloc
0000000000000000      DF *UND*  0000000000000000  DATRIE_0.2
trie_state_is_walkable

All datrie calls from libthai seem to be versioned, while libdatrie0
symbols aren't:

$ objdump -T /usr/lib/libdatrie.so.0.0.3

/usr/lib/libdatrie.so.0.0.3:     file format elf64-x86-64

DYNAMIC SYMBOL TABLE:
0000000000000f58 l    d  .init  0000000000000000              .init
0000000000000000      DF *UND*  0000000000000148  GLIBC_2.2.5 ftell
0000000000000000  w   D  *UND*  0000000000000000              __gmon_start__
0000000000000000  w   D  *UND*  0000000000000000
_Jv_RegisterClasses
0000000000000000      DF *UND*  000000000000011e  GLIBC_2.2.5 fseek
0000000000000000      DF *UND*  00000000000001de  GLIBC_2.2.5 malloc
0000000000000000      DF *UND*  000000000000000a  GLIBC_2.2.5 fopen
0000000000000000      DF *UND*  00000000000001c2  GLIBC_2.2.5 fgets
0000000000000000      DF *UND*  0000000000000057  GLIBC_2.2.5 __strdup
0000000000000000      DF *UND*  00000000000000d9  GLIBC_2.2.5 free
0000000000000000      DF *UND*  00000000000000e9  GLIBC_2.2.5 strlen
0000000000000000  w   DF *UND*  00000000000000fe  GLIBC_2.2.5 __cxa_finalize
0000000000000000      DF *UND*  0000000000000090  GLIBC_2.2.5 sprintf
0000000000000000      DF *UND*  0000000000000090  GLIBC_2.2.5 sscanf
0000000000000000      DF *UND*  00000000000000f3  GLIBC_2.2.5 rewind
0000000000000000      DF *UND*  00000000000001bc  GLIBC_2.2.5 strcat
0000000000000000      DF *UND*  000000000000018f  GLIBC_2.2.5 memmove
0000000000000000      DF *UND*  0000000000000155  GLIBC_2.2.5 fread
0000000000000000      DF *UND*  00000000000000dc  GLIBC_2.2.5 strcpy
0000000000000000      DF *UND*  0000000000000213  GLIBC_2.2.5 fclose
0000000000000000      DO *UND*  0000000000000008  GLIBC_2.2.5 stderr
0000000000000000      DF *UND*  0000000000000187  GLIBC_2.2.5 fwrite
0000000000000000      DF *UND*  00000000000002e8  GLIBC_2.2.5 realloc
0000000000000000      DF *UND*  0000000000000090  GLIBC_2.2.5 fprintf
00000000000037c0 g    DF .text  0000000000000034  Base        sb_trie_state_walk
0000000000002cf0 g    DF .text  0000000000000005  Base        trie_state_free
0000000000002ed0 g    DF .text  00000000000000ef  Base        trie_retrieve
0000000000003150 g    DF .text  0000000000000210  Base        trie_store
0000000000003820 g    DF .text  0000000000000022  Base        sb_trie_state_free
0000000000002b50 g    DF .text  0000000000000020  Base
trie_state_get_data
0000000000002dc0 g    DF .text  0000000000000029  Base        trie_enumerate
0000000000003a90 g    DF .text  0000000000000069  Base        sb_trie_store
0000000000002fc0 g    DF .text  00000000000000f2  Base        trie_delete
0000000000003bc0 g    DF .text  00000000000000a5  Base        sb_trie_open
0000000000003780 g    DF .text  0000000000000034  Base
sb_trie_state_is_walkable
00000000000033f0 g    DF .text  000000000000009d  Base        trie_open
0000000000003760 g    DF .text  0000000000000013  Base
sb_trie_state_is_terminal
0000000000003720 g    DF .text  0000000000000016  Base
sb_trie_state_get_data
00000000000033a0 g    DF .text  0000000000000041  Base        trie_close
0000000000002bf0 g    DF .text  000000000000002c  Base        trie_state_is_leaf
0000000000003800 g    DF .text  0000000000000012  Base
sb_trie_state_rewind
0000000000003b70 g    DF .text  0000000000000016  Base        sb_trie_save
0000000000002d00 g    DF .text  0000000000000062  Base        trie_state_clone
0000000000003b90 g    DF .text  0000000000000027  Base        sb_trie_close
0000000000003360 g    DF .text  000000000000003a  Base        trie_save
0000000000003850 g    DF .text  0000000000000058  Base
sb_trie_state_clone
0000000000002cd0 g    DF .text  000000000000001b  Base        trie_state_rewind
0000000000003740 g    DF .text  0000000000000013  Base
sb_trie_state_is_leaf
0000000000003b00 g    DF .text  0000000000000068  Base        sb_trie_retrieve
00000000000038b0 g    DF .text  0000000000000053  Base        sb_trie_root
0000000000002b70 g    DF .text  0000000000000074  Base
trie_state_is_walkable
0000000000002d70 g    DF .text  000000000000004c  Base        trie_root
0000000000002c20 g    DF .text  00000000000000a7  Base        trie_state_walk
0000000000003a30 g    DF .text  0000000000000057  Base        sb_trie_delete
0000000000003910 g    DF .text  0000000000000030  Base        sb_trie_enumerate

However, unstable pango still doesn't work. It crashes leafpad
and gucharmap, but not gedit. And when checking process map,
gedit doesn't care about LD_LIBRARY_PATH and only loads libthai
from /usr/lib. But the other two do load it from /usr/local/lib, and crash.

I must be missing something here. :-/

Regards,
--
Theppitak Karoonboonyanan
http://linux.thai.net/~thep/


--
To UNSUBSCRIBE, email to debian-gtk-gnome-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Theppitak Karoonboonyanan]

On Tue, Mar 31, 2009 at 5:55 PM, Theppitak Karoonboonyanan
<thep@...> wrote:
> On Tue, Mar 31, 2009 at 4:56 PM, Josselin Mouette <joss@...> wrote:

>> However, thinking about it again, if you add symbol versions in libdatrie1,
>> this should work. Since pango doesn't actually use any symbols from
>> libdatrie, all required symbols will be required with a version, so the
>> correct ones will be selected.
>
> I suppose so. However, I've tried it and found no luck so far.
> For the experiment, I've used "-Wl,--version-script=libdatrie.map"
> LDFLAG instead of libtool -export-symbols flag, and list all
> currently exported symbols under DATRIE_0.2 { global: ...; };
> (with a "local: *" catch all in it, of course). Then I rebuilt both
> libdatrie and libthai.
>
> ...
>
> However, unstable pango still doesn't work. It crashes leafpad
> and gucharmap, but not gedit. And when checking process map,
> gedit doesn't care about LD_LIBRARY_PATH and only loads libthai
> from /usr/lib. But the other two do load it from /usr/local/lib, and crash.
>
> I must be missing something here. :-/

I have got a dirty hack: by adding symbol versioning to libdatrie0.
This solves the upgrading crash without breaking the current apps in
unstable. But I'm not sure if it's a good practice in terms of package
maintenance. Do you think doing so is considered ABI breakage?

Probably, adding Conflicts is the most suitable solution.

Regards,
--
Theppitak Karoonboonyanan
http://linux.thai.net/~thep/


--
To UNSUBSCRIBE, email to debian-gtk-gnome-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Theppitak Karoonboonyanan]

On Wed, Apr 1, 2009 at 9:27 AM, Theppitak Karoonboonyanan
<thep@...> wrote:

> I have got a dirty hack: by adding symbol versioning to libdatrie0.
> This solves the upgrading crash without breaking the current apps in
> unstable. But I'm not sure if it's a good practice in terms of package
> maintenance. Do you think doing so is considered ABI breakage?

Answering to myself: I don't think so. I'll update the old
libdatrie branch soon.

--
Theppitak Karoonboonyanan
http://linux.thai.net/~thep/


--
To UNSUBSCRIBE, email to debian-gtk-gnome-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Josselin Mouette]

Le mercredi 01 avril 2009 à 09:27 +0700, Theppitak Karoonboonyanan a
écrit :
> I have got a dirty hack: by adding symbol versioning to libdatrie0.
> This solves the upgrading crash without breaking the current apps in
> unstable. But I'm not sure if it's a good practice in terms of package
> maintenance. Do you think doing so is considered ABI breakage?

It is not ABI breakage, but it is useless, since this won’t fix
libdatrie in lenny.

--
 .''`.      Debian 5.0 "Lenny" has been released!
: :' :
`. `'   Last night, Darth Vader came down from planet Vulcan and told
  `-    me that if you don't install Lenny, he'd melt your brain.

[Theppitak Karoonboonyanan]

2009/4/1 Josselin Mouette <joss@...>:
> Le mercredi 01 avril 2009 à 09:27 +0700, Theppitak Karoonboonyanan a
> écrit :
>> I have got a dirty hack: by adding symbol versioning to libdatrie0.
>> This solves the upgrading crash without breaking the current apps in
>> unstable. But I'm not sure if it's a good practice in terms of package
>> maintenance. Do you think doing so is considered ABI breakage?
>
> It is not ABI breakage, but it is useless, since this won’t fix
> libdatrie in lenny.

It's not totally useless, though. At least, it should allow the new
libthai to enter sid and squeeze without down time, whether
or not its rdepends are rebuilt with '-ldatrie' dropped in the
mean time.

Nevertheless, I'll still add versioned conflict against libdatrie0
(<< 0.1.4) on next upload. Thanks for the check.

Regards,
--
Theppitak Karoonboonyanan
http://linux.thai.net/~thep/


--
To UNSUBSCRIBE, email to debian-gtk-gnome-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...