zorba-coders team mailing list archive

[Chris Hillery <862089@xxxxxxxxxxxxxxxxxx>]

Public bug reported:

This is at the request of the Fedora package maintainer.

Currently Zorba installs the .xq (and .xsd) files for schemas and the
.so/.dll files for module external functions into the same directory, by
default share/zorba-VERSION/modules. This does not meet Fedora packaging
requirements, which state that any platform-dependent files such as .so
files must go into lib/lib64 directories. Ideally, non-platform
dependent files such as .xq and .xsd should be filed in share.

There is another problem with the above scheme: since this directory is
where non-core modules will install themselves also (and the only place
Zorba will look for them), they are implicitly tied to Zorba's version
number even though they should have independent versioning.

The proposal is to split this into a total of four directories:
platform-dependent/platform-independent, and Zorba-version-specific/non-
Zorba-version-specific (ie, core modules vs. non-core modules). So, for
instance:

CMAKE_INSTALL_PREFIX/
     share/
          modules/
          core-modules/
               2.1/
     lib64/
          modules/
          core-modules/
               2.1/

where "2.1" is the Zorba version.

The easy way to do this would be to simply put all of the above on the
default module-path, and change the install process to put everything in
the right places. One downside to this is that it means Zorba will look
in many wrong places when doing any URI resolution and when loading .so
files - it knows it is looking for (say) an .xq file, but it will look
in the two lib/ directories as well because they're all on the same
module path.

A better way to do this would be to separate the concepts inside Zorba
as well, and have a "URI Path" for all URI resolution which is separate
from the "module path" which is used for loading external function
libraries. Zorba could do that for itself easily enough. The only issue
is what would be the interpretation of --module-path (and the
corresponding C++ API function) - would that be a backward-incompatible
change?

** Affects: zorba
     Importance: High
     Assignee: Chris Hillery (ceejatec)
         Status: New

** Changed in: zorba
   Importance: Undecided => High

** Changed in: zorba
     Assignee: (unassigned) => Chris Hillery (ceejatec)

-- 
You received this bug notification because you are a member of Zorba
Coders, which is the registrant for Zorba.
https://bugs.launchpad.net/bugs/862089

Title:
  Split binary/xq install directories for modules

Status in Zorba - The XQuery Processor:
  New

Bug description:
  This is at the request of the Fedora package maintainer.

  Currently Zorba installs the .xq (and .xsd) files for schemas and the
  .so/.dll files for module external functions into the same directory,
  by default share/zorba-VERSION/modules. This does not meet Fedora
  packaging requirements, which state that any platform-dependent files
  such as .so files must go into lib/lib64 directories. Ideally, non-
  platform dependent files such as .xq and .xsd should be filed in
  share.

  There is another problem with the above scheme: since this directory
  is where non-core modules will install themselves also (and the only
  place Zorba will look for them), they are implicitly tied to Zorba's
  version number even though they should have independent versioning.

  The proposal is to split this into a total of four directories:
  platform-dependent/platform-independent, and Zorba-version-specific
  /non-Zorba-version-specific (ie, core modules vs. non-core modules).
  So, for instance:

  CMAKE_INSTALL_PREFIX/
       share/
            modules/
            core-modules/
                 2.1/
       lib64/
            modules/
            core-modules/
                 2.1/

  where "2.1" is the Zorba version.

  The easy way to do this would be to simply put all of the above on the
  default module-path, and change the install process to put everything
  in the right places. One downside to this is that it means Zorba will
  look in many wrong places when doing any URI resolution and when
  loading .so files - it knows it is looking for (say) an .xq file, but
  it will look in the two lib/ directories as well because they're all
  on the same module path.

  A better way to do this would be to separate the concepts inside Zorba
  as well, and have a "URI Path" for all URI resolution which is
  separate from the "module path" which is used for loading external
  function libraries. Zorba could do that for itself easily enough. The
  only issue is what would be the interpretation of --module-path (and
  the corresponding C++ API function) - would that be a backward-
  incompatible change?

To manage notifications about this bug go to:
https://bugs.launchpad.net/zorba/+bug/862089/+subscriptions