harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregory Shimansky <gshiman...@apache.org>
Subject Re: [doc] new header dependency in awt on Linux - x11proto-xext-dev
Date Wed, 23 Jan 2008 10:48:06 GMT
Egor Pasko said the following on 22.01.2008 14:43:
> Gregory,
> 
> I committed the initial proposed damn simple change since it makes
> things slightly better. I am also open for discussions :)

It is better than nothing :)

> On the 0x3D0 day of Apache Harmony Egor Pasko wrote:
>> On the 0x3D0 day of Apache Harmony Gregory Shimansky wrote:
>>> On 18 января 2008 Egor Pasko wrote:
>>>> On the 0x3CF day of Apache Harmony Gregory Shimansky wrote:
>>>>> Egor Pasko said the following on 18.01.2008 17:47:
>>>>>>> In the docs it should be written that if some header ... is not
>>>>>>> present, it the package x11proto-xext-dev should be installed,
>>>>>>> otherwise it may confuse people who are using distros that provide
>>>>>>> this header in other package.
>>>>>> Igor Stolyarov said in FC it is the same, Debian has the same. Why
>>>>>> bother? gentoo? :)
>>>>> Well, as I've written, it doesn't exist on SuSE too.
>>>> I suggest to put at most 2 columns: for rpm-based and for apt-based
>>>> distros. Installing all packages is quick and easy, while
>>>> checking/installing by header is not.
>>> Well. I think that there should be a note about Debian based distros (since 
>>> apt as well as rpm are just package managers and may be used across different

>>> distributions). That should include Ubuntu, Kubuntu and other flavors of 
>>> Debian (unless they decide to split packages on their own accord). BTW are 
>>> you sure that this x11proto-xext-dev is not Ubuntu specific and is actually 
>>> required on Debian too?
>> Judging by [1] it is required in Debian. OK, mentioning Debian-based
>> instead of apt-based is a good point.
>>
>>> Saying this, the instructions of every possible Linux distro in the world are

>>> going to be hard to write. Versions change, packages are split, merged back 
>>> and renamed with different names, there is never going to be a perfect 
>>> instruction, especially considering the lag of the site and documentation 
>>> after the real state of things.
>>>
>>> I think the instruction should name the groups of packages by origin like
>>>
>>> X11 with all of its extensions and development packages
>>> libpng with all of its development packages
>>> libjpeg with all of its development packages
>>> liblcms with all of its development packages
>>> libxml2 with all of its development packages
>> ..and do not forget to mention, dynamic or static libs, and if static
>> then fPIC on x86_64, (also IPF, PPC), what else? :)
>>
>>> and so on.
>> I do not want an absolutely correct instruction like this. liblcms
>> could be split or merged with something else. No guarantee here as
>> well as in package names. And finally, such instruction is not very
>> usable.
>>
>> Giving package names is useful for a wide audience. And those
>> instructions that are there now (gy Geir?) helped me to set up my new
>> system very quickly without searching/detecting how the packeges are
>> named.
>>
>> So, if we want to be absolutely precise, let's put it like this:
>>
>> 1. here is the set of packages one needs to install for popular
>>    Debian-based distributions (Ubuntu, Knoppix, Linspire...)
>>
>> 2. here is the set for the RPM-based (Fedora, Mandriva, ALT, ...)
>>
>> 3. and here is the complete list of headers/libs requirements for the curious
>>
>> does it suit well? I will support list (1) then.
>>
>>> You and me would understand what it means. New developers would ask questions

>>> on dev list in any case, and this is not bad IMHO.
>> Asking questions is good, but many of newbies do not like to go this
>> list to ask starter questions. And I can understand them. So, let's
>> make the process of joining the fun as smooth and trivial as possible
>> (for most popular distros:) let's welcome developers instead of
>> showing how complex and difficult we can be.

-- 
Gregory


Mime
View raw message