Gnome-2.6 panel icons missing

Tracy Riegle triegle at comcast.net
Mon Apr 19 06:51:59 PDT 2004


In order then to avoid the "gotchas" should BLFS:

1. include a warning that things may break if installed somewhere other 
than /usr or /usr/local.
2. stear away all together from installing somewhere else.
or
3. Put more emphasis on using package management.

Keep in mind that LFS / BLFS is targeted at those who want to learn how 
a linux system works and not those who already know. The gotchas can be 
very confusing and frustrating for those wanting to learn (and very 
educational too speaking from experience.)

Dagmar d'Surreal wrote:

>On Sun, 2004-04-18 at 06:18, delgarde at ihug.co.nz wrote:
>  
>
>>Dagmar wrote:
>>    
>>
>>>You, unlike the vast unwashed masses, are actually using a
>>>package manager to solve a problem of package management.
>>>Congratulations.
>>>      
>>>
>>Thanks for the sarcasm, Dagmar, but is it really necessary?
>>Unlike distribs, LFS doesn't provide package management, so
>>we have to improvise our own. And so problems like this come
>>up - it may not be the fault of Gnome that it doesn't handle
>>multiple install paths, but it *is* a poorly documented
>>gotcha for people like us trying to work things out. It's
>>not written with people like LFSers in mind...
>>    
>>
>
>That wasn't sarcasm.
>
>...and it's not a "poorly documented gotcha".  It's _always_ been
>assumed that packages of the same vein are going to have the same
>arguments passed to their configure scripts.  The parts that are
>breaking when people put some packages into one set of locations and
>some packages in another are parts that _they_ are breaking by doing
>this.
>
>Things like the application .desktop files, for instance.  Those have a
>place where Gnome and KDE originally put them, as well as the common
>place that the FDO specs now specify, where they're both now putting
>them.  Icons as well.  This stuff is defined over at
>http://www.freedesktop.org/Standards/menu-spec and
>http://www.freedesktop.org/Standards/basedir-spec and they have no exact
>autoconf template analogues.  XDG_DATA_HOME, XDG_CONFIG_HOME, and so on
>are built up within _each_ package based on what you've passed with the
>usual configure arguments of sysconfdir and prefix and so on.  These
>mechanisms are correct, and they are well documented enough--users just
>aren't reading the documentation.  They're doing things haphazardly and
>expecting them to work, seeing that they don't, and then claiming
>they're broken without ever researching why or what specifically broke
>for them, which is why I'm now having to write this email.
>
>Time and time again, the reasons people are citing for having tried to
>put things into /opt (or any other prefix) are for the purposes of
>package management.  There are _many_ package managers out there that
>can keep simple file inventories, but folks act like they're above
>needing such things, so they decide instead to merely install things
>into directories they can easily delete.  Note that _no_ widely used
>package management programs do this.  (Stow doesn't just stick files in
>a directory, it adds a massive number of symlinks to compensate for the
>effects of it's actions.)  Are you seeing where I'm going with this yet?
>
>Think of it like putting parts into an engine based on a particular
>orientation, then closing your eyes and turning the car 90-degrees to
>the right halfway through.  This is the problem that's coming up. 
>(Pkgconfig gets around some of these problems, but it's only meant to
>solve the problem of where files are needed for compiling, not the
>problem of where files are at run-time, which is an entirely different
>animal.)
>
>Hopefully this will clear up the issue.  I'd been hoping I would never
>have to explicitly mention the FDO site, but c'est la vie.
>  
>




More information about the blfs-support mailing list