Opened 10 years ago

Closed 9 months ago

#587 closed activism (discarded)

RFC: separate doc, etc and share from lib

Reported by: epruesse Owned by: westram
Priority: normal Milestone:
Component: global Version: SVN
Keywords: Cc:

Description

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?

Change History (3)

comment:1 in reply to: ↑ description ; follow-up: Changed 10 years ago by 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)

comment:2 in reply to: ↑ 1 Changed 10 years ago by 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 users 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.

comment:3 Changed 9 months ago by westram

  • Owner changed from devel to westram
  • Resolution set to discarded
  • Status changed from new to closed

Arb was designed to completely reside in a single directory.
Arb installations on a host may be any number of user-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 users struggle with these versions :-(
Note: See TracTickets for help on using tickets.