[Bf-committers] relocatable blender on linux

GSR gsr.b3d at infernal-iceberg.com
Sun Jul 22 01:36:10 CEST 2007


Hi,
cbarton at metavr.com (2007-07-22 at 0721.38 +1000):
> GSR wrote:
> > Hi,
> > cbarton at metavr.com (2007-07-22 at 0128.04 +1000):
> >> At the moment blender on linux always points to ~/.blender/
> > 
> > Notice that it also points to ~/.B.blend and other files in ~/. There
> > is no unified dir and some other data is not truly compatible (quick
> > example is .B.blend). IMHO one of the first things to do would be to
> > unify all conf inside a dir and clean up the hidden issue (hidden
> > files inside it, does anybody has a good explanation?).
> Im not against relocating .B.blend etc but I think its a separate issue, 
> and no reason to do it first.

OTOH, I think it is pretty much related to the issue, as you want to
know what binary is really running to do things accordingly. It is not
a small issue, it needs to cover the issues of multiuser, portability
and versioning, to just mention the three that quickly come to mind,
instead of go with no plan and change and back step when issues pupop,
even if they were there from start.

Sometimes the data is compatible, sometimes not. Aside from ~/.B.blend
(already problematic, even if just when you want to run a really old
version), there are ~/.Bfs, ~/.Blog and ~/.Bfont, and inside $config
there are things like locale/ or scripts/ which have problems with
different releases. Currently things get spill over or duplicated in
~/, ~/.blender/ and $package/.blender/ (and $package/plugins/, but
those are just source, even if they could be provided ready to run).

For example, what to do if you have no write access to
$package/$config/bpydata/ because $package was unpacked by other user?
Or is system wide install (no write access and maybe even path is
unrelated to $binary)? Or what policy is taken for locale/?

The issue is not just relocating some inside, it is also relocating
things outside as needed and figure what is version dependant and what
not (and handling what was not but at some point became). In
conclusion, it is cleaning the problems for once, not just for
scripts/.

GSR
 


More information about the Bf-committers mailing list