rpm -qi libthai Name : libthai Relocations: (not Description : LibThai is a set of Thai language support routines aimed to ease developers' tasks to incorporate Thai language support in their applications. It includes important Thai-specific functions e.g. word breaking, input and output methods as well as basic character and string supports.
Not very important for a non-thai-speaker
[net@pietro ~]$ yum remove libthai
Dependencies Resolved
================================================================================ Package Arch Version Repository Size ================================================================================ Removing: libthai x86_64 0.1.9-4.fc9 installed 397 k libthai i386 0.1.9-4.fc9 installed 396 k Removing for dependencies:
AdobeReader_enu i4 86 8.1.2_SU1-1 installed 115 M GConf2-gtk x86_64 2.22.0-1.fc9 installed 12 k ImageMagick x86_64 6.3.8.1-4.fc9 installed 13 M ImageMagick-perl x86_64 6.3.8.1-4.fc9 installed 667 k Miro x86_64 1.2.7-1.fc9 installed 22 M NetworkManager-gnome x86_64 1:0.7.0-0.11.svn4022.4.fc9 installed 846 k PolicyKit-gnome x86_64 0.8-4.fc9 installed 265 k PolicyKit-gnome-libs
- snip-
installed 457 k xsane x86_64 0.995-3.fc9 installed 4.8 M xsane-gimp x86_64 0.995-3.fc9 installed 605 k xulrunner x86_64 1.9.0.2-1.fc9 installed 23 M yelp x86_64 2.22.1-5.fc9 installed 3.0 M zenity x86_64 2.22.1-1.fc9 installed 3.0 M
Transaction Summary ================================================================================ Install 0 Package(s) Update 0 Package(s) Remove 266 Package(s)
Is this ok [y/N]: no, of course. Remaining question: is this the way 'requires' should be used?
On Thu, 06 Nov 2008 15:03:20 +0100, Henk Breimer wrote:
rpm -qi libthai Name : libthai Relocations: (not Description : LibThai is a set of Thai language support routines aimed to ease developers' tasks to incorporate Thai language support in their applications. It includes important Thai-specific functions e.g. word breaking, input and output methods as well as basic character and string supports.
Not very important for a non-thai-speaker
[net@pietro ~]$ yum remove libthai
[....]
================================================================================ Install 0 Package(s) Update 0 Package(s) Remove 266 Package(s)
Is this ok [y/N]: no, of course. Remaining question: is this the way 'requires' should be used?
Thank you for posting that. I've been seeing much the same thing, for it seems like two or three releases now; and it has always wanted to take not only a huge number of things, but several that are crucial to my use. There has to be something wrong: I always remove umpteen dozen apps having to do with languages I never see, and then have to leave Thai.
Can somebody at least tell us *why* this patent aberration is arising?
On Thu, 6 Nov 2008 15:03:20 +0100, Henk Breimer wrote:
[net@pietro ~]$ yum remove libthai
Remove 266 Package(s)
Is this ok [y/N]: no, of course. Remaining question: is this the way 'requires' should be used?
You show that you don't understand the reason for this. This is a shared library that is linked with another system library: Pango. It results in an automatic 'Requires' on the libthai library SONAME in the pango package, since the library is required at run-time and isn't optional.
$ repoquery --whatrequires libthai.so.0 libthai-0:0.1.9-4.fc9.i386 pango-0:1.20.4-1.fc9.i386 libthai-devel-0:0.1.9-4.fc9.i386 scim-thai-0:0.1.1-2.fc9.i386 pango-0:1.20.1-1.fc9.i386
Pango in turn is required by many a dozen packages. Removing Pango creates a long dependency chain of packages that would need to be removed, too.
In case you want to remove a system library like LibThai, you would need to disable it in Pango -- or rewrite Pango to load the library as an optional plugin (that's likely harder).
On Thu, 06 Nov 2008 17:00:02 +0100, Michael Schwendt wrote:
On Thu, 6 Nov 2008 15:03:20 +0100, Henk Breimer wrote:
[net@pietro ~]$ yum remove libthai
Remove 266 Package(s)
Is this ok [y/N]: no, of course. Remaining question: is this the way 'requires' should be used?
You show that you don't understand the reason for this. This is a shared library that is linked with another system library: Pango. It results in an automatic 'Requires' on the libthai library SONAME in the pango package, since the library is required at run-time and isn't optional.
$ repoquery --whatrequires libthai.so.0 libthai-0:0.1.9-4.fc9.i386 pango-0:1.20.4-1.fc9.i386 libthai-devel-0:0.1.9-4.fc9.i386 scim-thai-0:0.1.1-2.fc9.i386 pango-0:1.20.1-1.fc9.i386
Pango in turn is required by many a dozen packages. Removing Pango creates a long dependency chain of packages that would need to be removed, too.
In case you want to remove a system library like LibThai, you would need to disable it in Pango -- or rewrite Pango to load the library as an optional plugin (that's likely harder).
With respect, I don't think you've even approached the point -- certainly not mine, if it's any different from Henk Breimer's. You're making a claim that, in essence, amounts to "Whatever is, is right" -- or, if you prefer, "It has to be done that way, because that's the way we did it." Some of us don't call that a reason; a history, maybe, or a historical accident -- but something to be remedied, not accepted helplessly.
Pango should never have required libthai in the first place -- not in a release -- not if libthai is anything remotely like what its name suggests. (And, btw, gpk and pirut before it both list it among apps that exist specifically for the benefit of those who prefer particular languages -- as of course they are welcome to do.)
I can imagine that it *did* require it, initially, if for instance its author wrote the first version in Thai. I applaud the achievement.
But do you really want to defend the fact that that requirement was not found, or else found and not remedied, by any other Fedora developers?
Do you want to assert that any and all apps should be left to continue indefinitely requiring whatever their first versions may happen to require, including endless variety of languages?
Surely not. We have developers all over the world, who must think, and often write (first drafts at least), in a vast number of languages. Should we jam some latter-day Tower of Babel into Fedora?
Are we to throw away the huge benefit that fell into our laps when the Internet developed a lingua franca from its outset?
If it had arisen, like so much early technology, in a thousand places speaking a thousand tongues (many since extinct), would we be where we are, or even near??
What if all kernel development had required mastery of Finnish, and still did?? (I ask that as one who happens to take great delight in Finnish; I found it glorious fun to learn. Some of you might not.)
On Thu, 6 Nov 2008 22:13:55 +0000 (UTC), Beartooth wrote:
Pango should never have required libthai in the first place -- not in a release -- not if libthai is anything remotely like what its name suggests.
You could have replaced your overly long mail with the result of taking a look at what exactly in Pango requires LibThai. Here, look!
$ rpm -ql pango|grep thai /usr/lib/pango/1.6.0/modules/pango-thai-fc.so /usr/lib/pango/1.6.0/modules/pango-thai-lang.so
$ ldd /usr/lib/pango/1.6.0/modules/*.so|grep thai /usr/lib/pango/1.6.0/modules/pango-thai-fc.so: /usr/lib/pango/1.6.0/modules/pango-thai-lang.so: libthai.so.0 => /usr/lib/libthai.so.0 (0x00281000)
$ ldd /usr/lib/libpango*|grep thai $
Files that likely could go into an optional sub-package. Though, there's an additional explicit "Requires: libthai ..." in the spec, too:
$ grep -i thai pango.spec %define libthai_version 0.1.9 Requires: libthai >= %{libthai_version} BuildRequires: libthai-devel >= %{libthai_version} - Bump libthai requirement. - [Build]Require libthai[-devel] - Fix problem with corrupt Thai shaper
But do you really want to defend the fact that that requirement was not found, or else found and not remedied, by any other Fedora developers?
Did I defend it? No. I only pointed out that currently, Pango requires this library, and hence you cannot "yum remove" the lib without removing Pango and hundreds of deps that require Pango.
What exactly is the problem? It's just a tiny system library isn't it? Increased core functionality.
Beartooth wrote:
Pango should never have required libthai in the first place -- not in a release -- not if libthai is anything remotely like what its name suggests.
The alternatives are to a) write their own code for Thai font handling b) include libthai rather than link to it c) don't handle rendering Thai text. Either of the first two would do nothing to make the system any smaller, they'd just hide from you that Thai support was developed by someone outside the core Pango group.
As far as I know, they wrote their own code for all of the other scripts that are supported, and were able to use libthai because it was already available.
Surely not. We have developers all over the world, who must think, and often write (first drafts at least), in a vast number of languages. Should we jam some latter-day Tower of Babel into Fedora?
Yes, that's generally the idea. The system software should support the languages of a global user base. As a compromise, the fonts and locale information which constitute the largest use of storage are optional.
Are we to throw away the huge benefit that fell into our laps when the Internet developed a lingua franca from its outset?
I think you're confusing the purpose of libthai/pango (font rendering) with the purpose of UTF-8 (character encoding). Thai language support uses UTF-8 in Fedora, too.
On Thu, 6 Nov 2008 17:00:02 +0100 Michael Schwendt mschwendt@gmail.com wrote:
On Thu, 6 Nov 2008 15:03:20 +0100, Henk Breimer wrote:
[net@pietro ~]$ yum remove libthai
Remove 266 Package(s)
Is this ok [y/N]: no, of course. Remaining question: is this the way 'requires' should be used?
You show that you don't understand the reason for this. This is a shared library that is linked with another system library: Pango. It results in an automatic 'Requires' on the libthai library SONAME in the pango package, since the library is required at run-time and isn't optional.
$ repoquery --whatrequires libthai.so.0 libthai-0:0.1.9-4.fc9.i386 pango-0:1.20.4-1.fc9.i386 libthai-devel-0:0.1.9-4.fc9.i386 scim-thai-0:0.1.1-2.fc9.i386 pango-0:1.20.1-1.fc9.i386
Pango in turn is required by many a dozen packages. Removing Pango creates a long dependency chain of packages that would need to be removed, too.
In case you want to remove a system library like LibThai, you would need to disable it in Pango -- or rewrite Pango to load the library as an optional plugin (that's likely harder).
--
I fully understand what caused this.
My next question would be : "what would happen if such a helper program for every small lanquage were included in the same way?"
A better solution is needed for this kind of things.
Henk
Henk Breimer wrote:
I fully understand what caused this.
My next question would be : "what would happen if such a helper program for every small lanquage were included in the same way?"
Pango *is* a helper for every language. Thai just happens to be one case where the functionality required for rendering their language existed already and could be reused, rather than requiring the Pango team to write it themselves.
This is how software is *supposed* to work. The only problem is people who *aren't* involved in solving problems are bitching at the people who have, without even understanding the system that they're criticizing.
A better solution is needed for this kind of things.
If you think so, you're free to contribute one.
Gordon Messmer wrote:
Henk Breimer wrote:
I fully understand what caused this.
My next question would be : "what would happen if such a helper program for every small lanquage were included in the same way?"
Pango *is* a helper for every language. Thai just happens to be one case where the functionality required for rendering their language existed already and could be reused, rather than requiring the Pango team to write it themselves.
This is how software is *supposed* to work.
You mean all optional things are supposed to be linked whether needed at runtime or not?
Les Mikesell wrote:
Gordon Messmer wrote:
Henk Breimer wrote:
Pango *is* a helper for every language. Thai just happens to be one case where the functionality required for rendering their language existed already and could be reused, rather than requiring the Pango team to write it themselves.
This is how software is *supposed* to work.
You mean all optional things are supposed to be linked whether needed at runtime or not?
No, I mean that components should be reused to create broader, more capable, and more general components.
As far as linking goes, Pango gets that right, too. Pango's thai module is linked to libthai, and it's the only component that is. If you're concerned enough about 400k of disk, you can spend your time modifying the pango spec file to package the thai modules separately, and submit patches for the spec and for the distributions comps.xml file so that pango only gets Thai support when the user specifically installs Thai language support. However, you should consider the value of your time; creating those patches, testing them, and working with the maintainers to get them included is probably going to cost you considerably more than the disk space.