RFC: separate doc, etc and share from lib

[epruesse]

The lib directory currently contains a lot of stuff not "really" lib as in "architecture dependent stuff needed to run ARB". In theory:

share — data

• pictures
• pixmaps
• rna3d data

etc — configuration files

• import/export filter
• gde menus
• input masks
• predefined macros
• arb_tcp.dat
• selllists

doc — documentation

• *txt files
• licenses
• DTDs

Since those files aren't typically "built", and if so using different mechanisms, it might actually make sense to move them around in ARB and SVN. Although, then again, moving files in SVN is hairy…

What do you think? Worthwhile because it's easier to know where to find what if it's all in "standard" places, or just activism?

[westram]

Replying to epruesse:

What do you think? Worthwhile because it's easier to know where to find what if it's all in "standard" places, or just activism?

If you just want to move them inside SVN i consider it activism.

If you're looking forward to install them in /etc, /usr/share, etc. one day, i see several problems:

• how to handle multiple release-versions of arb on one machine? could use /etc/arb/6.0, /etc/arb/6.0.1, …
• release and SVN-WCs need to use different mechanisms to find their resources (if i debug arb-6.0.1, i don't want it to lookup them in /etc/arb/6.0.1)

[epruesse]

Replying to westram:

If you just want to move them inside SVN i consider it activism. If you're looking forward to install them in /etc, /usr/share, etc. one day,

I do. It's motivated by me messing with the Debian package and the ton of symlinks it has to set. Still, I think separating the types of files out in SVN might have some benefits. It's about house-keeping type cleanup in the end. E.g. there is lib/Makefile which is probably not intended to be distributed.

i see several problems:

• how to handle multiple release-versions of arb on one machine? could use /etc/arb/6.0, /etc/arb/6.0.1, …

Most people won't need more than one version of ARB installed at the same time. Or do you run multiple versions of Emacs?

Seriously though, typical install patterns are:

• /etc, /usr/{lib,share,bin,var}
• /etc, /usr/local/{lib,share,bin,var}
• /etc/opt/PACKAGE, /opt/PACKAGE-VERSION/{lib,share,bin,var}

So I'd just go for ${ARBHOME}/{etc,lib,share,bin,var}. If those are separate, a few symlinks will do the rest. It's just the current collection in lib, which requires a ton of links to separate out (not difficult, just fragile).

My point here, though, is also about making the ARB source a bit more easy to navigate. We have way more "configuration" type files than I had previously thought. Gathering them in an etc type folder makes sense I think. E.g. it shows interested what things they can mess with themselves. Giving resource files their own spot in share reduces the stuff that flies around in lib.

• release and SVN-WCs need to use different mechanisms to find their resources (if i debug arb-6.0.1, i don't want it to lookup them in /etc/arb/6.0.1)

I think that would be easily worked around by just putting them into ${ARBHOME}/etc. It's not much different from the current setup, only that libs are really just libs and configs go into etc.

I'm not 100% on the generated configs like arb.menu. The stuff in "etc" should really be plain, not built, I think.

[westram]

Arb was designed to completely reside in a single directory.
Arb installations on a host may be any number of -local or system-global directories.

Forcing arb into the standard linux directory schema

• would require much work + testing.
• interferes with parallel installation of multiple arb-versions.
• was done in a q&d manner for Launchpad- and apt-package-versions.
  Both versions have several problems, only caused by splitting arb up into system directories.
  Arb struggle with these versions