[Xastir-Dev] Re: New Directory Structure

[Alan Crosswell]

I have another suggestion for a directory change:  The places GPS maps are 
*written* needs to be configurable, and should probably be in ~/.xastir/ by 
default;  In a normal multi-user system, /usr/share/xastir/maps/GPS would not be 
writeable by mere users.  A knowledgable super-user could of course take 
shapefile maps from his .xastir/... directory and move them to 
/usr/share/xastir/maps as needed.
/a

Curt Mills, WE7U wrote:
> On Tue, 17 Jun 2003, Alan Crosswell wrote:
> 
> 
>>Attached find a replacement patch for the
>>xastir-datadir.patch.  It sticks XASTIR_DATA_BASE in CPPFLAGS instead of
>>in config.h, which makes the Makefile GNU compliant by permitting
>>$prefix (which $datadir is based on) to be redefined at make time (as
>>well as at configure time).  config.h considered harmful:-)
> 
> 
> Alan:  The new patch appears to work just fine!
> 
> So...  What do people think of the new structure?  Personally, I
> like it, but am a bit concerned as to how to get existing users
> migrated with little pain.  The benefits of this outweigh the pain
> of migrating, right?
> 
> So far I've needed to do this:
> 
> 
>     Close all Xastir sessions by all users
>     mv /usr/local/xastir /usr/local/share
>     Edit ~/.xastir/config/xastir.cnf:  Change "/usr/local/xastir" to
>         "/usr/local/share/xastir".
> 
> 
> Is there a way to automate the above, perhaps detecting during "make
> install" that the old heirarchy is in place, and moving things
> automatically/editing the config file?  If we could automate it so
> that the user doesn't have to worry about it, we could put these
> patches in fairly soon.  I'd hate to have to ask users to hand-edit
> their config files, or start a new config from scratch.
> 
> It'd be nice to do the moving of files out of /var/tmp at roughly
> the same time, although I think those are all hard-coded in the
> sources and not in the config file, so it's not as critical.  We can
> actually do it anytime.  Leaving old copies of the files in /var/tmp
> doesn't really hurt anything either.
>