fontconfig problems

[Nick Hudson]

On Mon, 2004-10-04 at 18:49 -0500, Chad Kittel wrote:
> On Monday 04 October 2004 06:24 pm, Nick Hudson wrote:
> > Xfree86* is no longer supported by us anymore, or atleast by me.  XOrg
> > is the future and we made a desicion when XOrg was released to go to
> > XOrg from now on.  I would suggest if you are running any Xfree86
> > servers still to upgrade to Xorg, you wont be sorry.
> 
> This wasn't a question reguarding me personally as I only run XOrg and have 
> been "since the begining."  I'm talking about our users that use the lunar 
> provided xfree86(-beta) modules still (god help their soles)... Are they 
> going be have issues with the fontconfig module being removed (or is this a 
> XOrg needed dependancy only?) -- as I look at 'lvu leert fontconfig', I see 
> my own answer, XOrg only... silly me.

Well yeah, it should work itself out normally due to the fact that all
the libs/headers between Xorg and XFree86 are the same names.  Yes XOrg
has updated them a bit but they should link the same.  I dont know of
any users who still use xfree86, if they still are I can only wonder
why.    


> 
> Back on the subject of xfree86 (and totally off topic from the thread)... What 
> is the future of these modules? How long are we planning on keeping them 
> around if they are not "supported?"  Can we create a module directory for 
> unsupport/deprecated modules and reloated them there? When we do phase those 
> out, we could get rid of two X profile modules:  'xserver' and 
> 'xservers-profile'

hopefully with the next update of XOrg I will get rid of the xfree86*
modules.  For the Lusers who still have Xfree86 installed it will be
just a matter of removing Xfree86 and installing XOrg.  Of course
**knocks on wood** things are never just that easy.  I cant think of any
problems they might have other than having to recompile a few modules
just to update the links.  Other than that I dont see a problem.

Nick


> 
> - Chad K
> >
> > Nick
> >
> > On Mon, 2004-10-04 at 18:05 -0500, Chad Kittel wrote:
> > > On Monday 04 October 2004 10:15 am, Nick Hudson wrote:
> > > > 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??
> > >
> > > Does this cause a problem with xfree86(-beta) users?  If it does, is it
> > > time to totally phase those modules out or are we still planning on
> > > supporting those?
> > >
> > > - Chad K.
> > >
> > > > 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
> > > >
> > > > _______________________________________________
> > > > Lunar-dev mailing list
> > > > Lunar-dev at lunar-linux.org
> > > > http://lunar-linux.org/mailman/listinfo/lunar-dev
> > >
> > > _______________________________________________
> > > Lunar-dev mailing list
> > > Lunar-dev at lunar-linux.org
> > > http://lunar-linux.org/mailman/listinfo/lunar-dev
> _______________________________________________
> Lunar-dev mailing list
> Lunar-dev at lunar-linux.org
> http://lunar-linux.org/mailman/listinfo/lunar-dev
-- 
Nick Hudson
Lunar Linux Dev Team
http://www.lunar-linux.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lunar-linux.org/mailman/private/lunar-dev/attachments/20041004/245bf9d8/attachment.bin