Alternate Installation Prefixes [Was: Re: Gnome-2.28.0 build notes -- Compatability Symlinks]

Wayne Blaszczyk wblaszcz at bigpond.net.au
Sat Oct 24 19:49:19 PDT 2009


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

DJ Lucas wrote:
> On 10/24/2009 04:30 AM, Lars Bamberger wrote:
>> DJ Lucas wrote:
>>    
>>> This is mostly for Wayne, but anyone else working on Gnome-2.28.0, I'm
>>> building in the /opt/gnome-2.28.0 prefix as opposed to /usr and thought
>>> these build notes might be useful.
>>>      
>> Same here.
>>
>> On my system I created some "compatibility" symlinks:
>>
>> $GNOME_PREFIX/share/icons ->  /usr/share/icons
>> $GNOME_PREFIX/share/pixmaps ->  /usr/share/pixmaps
>> $GNOME_PREFIX/python$PYTHON_VERSION ->  /usr/lib/python$PYTHON_VERSION
>> $GNOME_PREFIX/lib/gio ->  /usr/lib/gio/modules
>>
>> This works for me, but it might also break things as some packages might
>> step on each others toes. Anyhow one might consider putting these
>> instructions in the book at one time.
>>
>> Lars
>>    
> Unfortunately, it is a slow, time consuming process to validate a set of 
> instructions as large as the Gnome stack.  KDE and Xorg suffer the same 
> issues, but are certainly a little more forgiving than the 6 month Gnome 
> release cycle.  Gnome will be a *little* more manageable with 2.30/3.0 
> with art, bonobo, canvas, eel, glade, print, *ui, and all their 
> dependencies gone.  However, it seems that the developers aren't really 
> concerned with alternate installation prefixes, they obviously do not 
> test this scenario, and the patches and 'fixes' required will continue 
> to grow.  Upstreaming the patches has mixed results.
> 
> I've hinted at this suggestion before, and mulled this over for a while 
> now.  I'm now suggesting that BLFS no longer support the alternate 
> installation prefixes for X, Gnome, and KDE.  The alternate prefixes can 
> be supported by the wiki if people are willing to commit to it.
> 
> What does everyone else think of this?
> 
> -- DJ Lucas
> 
This would be my preference as well, but after reading all the other
emails, I can see the need to keep the alternative prefix option. There
are three reasons why I use /usr, one, I like everything that is part of
my base system to be under /usr, two, I could not see myself having two
versions of anything, and thirdly, it eliminates most of these prefix
problems. If I had my way, I would even get rid of the /etc/gnome/<ver>
prefix which has also caused some grief , but have comprised and left it
so that I can contribute to this project. I don't see the developers
ever fully supporting an alternative prefix installation unless there
was a mandate placed on the GNOME project to do so. I can also see the
problems faced from the developers point of view. If you take the
extreme example of someone installing every package in it's own unique
directory, as a developer you would have to have a prefix option for
almost every dependency that that package would use, and that in itself
would be a nightmare to test or maintain. The above scenario would also
lead to having multiple locations of where icons could be found. Would
it then become the duty of the developer to allow for multiple icon
locations, or the duty of the installer/builder to be a bit more
sensible and have a single location for icons i.e. use the same prefix?
   I think this also shows the importance of standards.
Regards,
Wayne.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFK47yvhfgHoRhX2wIRApeiAJ94AnmdgJWxCGstlzA8wt1BSyK8OwCg49bd
++B4KvL/nH8xkJ5lABXvbu8=
=QRME
-----END PGP SIGNATURE-----



More information about the blfs-dev mailing list