Monday, July 2, 2007

First steps at making OPIE fit well with OE filesystem structure

One of the requirement set for OPIE to be supported for Angstrom was compliance with standard GNU/Linux installation location ($prefix and friends). There was bug in OE long enough for this, with few developers considering how to proceed with this.

I finally found time to test some ideas from it, and initial conversion from /opt/QtPalmtop to /usr went pretty smooth requiring besides rebuild few fixes to packages where the former path was harcoded in the literal form. Resulting opie-image booted in QEMU quite well, so I went with committing it, bumping snaphost date for OPIE 1.2.3-pre to 20070702 at the same time.

Hope other developers will help with testing it, and then the conversion needs to be fixed by moving data and plugin to appropriate locations (now they live at places like /usr/pics). This would take a bit more effort exactly because of this dichotomy - data vs plugins, with first should be living under /usr/share, and the latter (ideally) under /usr/lib. I wonder, if a solution like making QTDIR, etc. environment variables to accept list of paths is good enough (well, it is generic from system design point of view, but adds extra runtime overhead).

3 comments:

  1. I wait end of your work for doing something like that with qtopia

    ReplyDelete
  2. /opt is a standard GNU/Linux installation directory in the Filesystem Hierarchy Standard for add-on software packages.

    http://www.pathname.com/fhs/2.2/fhs-3.12.html

    This aversion for /opt is a bit silly.

    ReplyDelete
  3. 2 lorn:

    My doing that is based on the very simple fact: I (and other OPIE/OE maintainers) got that as a requirement for OPIE support in Angstrom. Whil I myself perceive that as not very good investment of effort, I at least barely can understand it. First off all, it is simply inconsistent with other software (where X stuff should be installed? Back into /usr/X11R6?). Secondly, there're no good reasons why it is installed there in the first place (following by now long time legacy conventions of peculiar systems is hardly good reason). And finally, it doesn't adhere to quoted FHS standard, as OPIE as produced by OE in corresponding images, is not addon software, but core UI system itself.

    So, in the end, I'm glad this is being done, as it clearly sets mind on "clean up" path, with other things which used to seem hard to touch now in queue.

    ReplyDelete