Re: dependency champion?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.)

-- 
Beartooth Staffwright, PhD, Neo-Redneck Linux Convert
I do know something about multilingual groups, and the history of tongues.

-- 
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora Magazine]     [Fedora News]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [SSH]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux