DirectoryReorgProposal
Directory Reorganization Proposal
[Iniitally proposed Feb 11, 2004 by B. Harrington on inkscape-devel@]
Distribution / Packaging Files
Presently, we have a number of files in the codebase related to generation of distribution packages. Some of these files are in the root inkscape/ directory, others are in subdirs like inkscape/debian/.
To head off potential clutter as Inkscape becomes supported on a wider variety of systems, we should collect as many of these packaging files as feasible into a subdir called inkscape/packaging/.
Inside that directory would be distro-specific subdirs, plus a common directory for shared scripts and collateral:
inkscape/packaging/
common/
debian/
fedora/
fink/
mandrake/
suse/
Config Files
Currently we do not have global config files, but instead put the config file in the user's home dir in ~/.inkscape/. These are generated at run-time by Inkscape itself, so the defaults are hard-coded into the application, and can't be customized by the sysadmin except by editing the appropriate header file and recompiling/repackaging the app.
The correct approach for Linux apps is to have both user and global configs, and to use the global as the default if the user does not yet have a config file. This way, site customizations are known (such as the fact that its shared files are in /usr/share, vs. /usr/local/share, vs. /opt/inkscape/share, etc.)
The proposal is for Inkscape to establish its config file location in /etc/inkscape/, and to place a global preferences.xml file there, as well as any other config files we need later, like extensions.xml, etc.
Ideally, the global config file would be loaded first, and then the user config file "override" any portion of the global options. This way the user config file only needs to contain customizations, so that if we choose to change the defaults in a future install, the user's config files do not necessarily become invalid.
Inside the CVS codebase, the default etc. files would be stored in inkscape/etc/, instead of being produced by the application at runtime. During installation, installation-specific parameters (such as alternate paths for various files) will be substituted in appropriately.
[Note: There is a proposal to use GConf in favor of flat config files, which would make this section of the proposal unnecessary. -- Bryce]
Inkscape currently generates a /usr/local/share/inkscape/ directory during install, and copies the contents of the codebase's icons/ directory to that location.
We need more pieces of collateral installed, and need to do so in a more organized manner. The recommendation is to establish a set of subdirs in /usr/local/share/inkscape/, as follows:
AUTHORS
NEWS
clipart/
examples/
extensions/
fonts/
gradients/
icons/
keyboards/
markers/
palettes/
patterns/
screens/
about.svg
templates/
tutorials/
This uses a flat hierarchy for the sake of simplicity.
In the CVS codebase, all of these would be placed in inkscape/share/ (except AUTHORS and NEWS which will be copied to share). This way, the installation script could be set up to recursively copy everything in that directory to the target share directory, and we won't need to specify each of the subdirs in that script, which will make maintenance less hassle.
For clipart, I think we definitely want to consider being able to tie in with "external" clipart collections. One way would be to simply put symlinks in the clipart dir to those collections. This way, if the flags package were to install into /usr/share/flags-svg/, we'd just symlink there.
Possibly similarly for extensions.
I think an argument could be made that the tutorials ought to be placed somewhere under the /usr/doc/ or /usr/local/doc/ path, so I'm not 100% certain of having the tutorials located here.