fontconfig problems

[Nick Hudson]

I may or maynot have a nice solution to the fontconfig problems.  
Instead of using the fontconfig module, why dont we use fontconfig that 
comes with XOrg??  This way fontconfig is updated each time XOrg is, 
also it would minimize the risk of problems.  Since Xorg is on a release 
schedule so is fontconfig and with each release fontconfig will be 
updated to the latest version.  Let me know what you think?? 

Also I have a few more tests to run on the new version of XOrg, but it 
doesnt look like it will be much longer on getting a new release out.  
Once I do that then I can start on Gnome 2.8.  Speaking of Gnome 2.8 how 
close are we on having a "stable" 2.6 kernel??  When are we planning on 
moving to a 2.6 kernel??  Gnome 2.8 depends heavly on Gnome 2.8, 
expecially DBUS and HAL. 

Nick



Auke Kok wrote:

> Jerry Lundström wrote:
>
>> Nick Hudson wrote:
>>
>>> Yeah its a good idea, or maybe we could update fontconfig with a new 
>>> XOrg release and just have them recompile together??  Either way 
>>> sounds like a better plan.   ATM I have some major issues with 
>>> getting any xserver to compile so I cant test any of this till it 
>>> gets fixed, but I think if we only update fontconfig when a new XOrg 
>>> version comes out this wont happen again.  Or we can just spawn off 
>>> a Xorg, Pango and Gtk2 rebuild after you compile fontconfig.
>>
>>
>
> I was hoping something "shorter" and "sooner". I'm sure we can come up 
> with an informational message (the fontconfig upgrade was how long 
> ago?) that at least explains the issue and suggests the easiest 
> approach *today*.
>
>> Why not just do a lunar rebuild everytime you install a module? that 
>> way we never need to bother checking what new versions/module do.
>
>
> well erm
>
>>
>> ...
>> ...
>> ...
>> ...
>>
>> OR MAYBE we should start taking care of libraries?!?!
>
>
> go get your coffee first, read your comics and think again
>
>>
>> We dont make any effort in checking how libs are installed today and 
>> if we dont start this will not be the first problem we will have.
>> If you havn't noticed libexpat change a few weeks ago, it installed 
>> itself as .so.1 and suddenly changed to .so.0 breaking some other 
>> programs that was linking to .so.1 .
>>
>> Sure we can ignore the big problem and just tell everyone to rebuild 
>> most of thier system when a lib change.... or we could global 
>> solution/guideline on how to deal with libs.
>
>
>
> neither works, lunar is still a distro that requires manual 
> intervention and the more we automate the solution the more software 
> is rebuilt and the more problems you will get if you don't cover all 
> corners.
>
> We cannot cover all corners.
>
> That said I don't think we should let this pass but I am much more 
> enthusiastic to frequent communications from the dev group towards 
> users about possible issues and guidelines etc than increasing the 
> load on our users. This comes from 2 viewpoints:
>
> 1) our users are smart
>
> 2) our users can be smarter if we tell em how
>
> Everytime I fix a core bug I am ashamed about the amount of 
> documentation we have. At least I am trying to communicate horizontal 
> and vertical to cover my ass in this type of problems.
>
>> I leave it up for the collective decision of ALL lunar-devs (in other 
>> words, reply to this thread or your say has nothing of value).
>
>
> ehmmmmmm did you get your coffee yet?
>
> okay you do have a point. I'll come back to it later.
> _______________________________________________
> Lunar-dev mailing list
> Lunar-dev at lunar-linux.org
> http://lunar-linux.org/mailman/listinfo/lunar-dev