Forum OpenACS Q&A: Package Dependencies in OpenACS

Collapse
Posted by Nima Mazloumi on
Hi all,

we have discussed the subject of packages dependencies here in our team and defined a more or less automatical process to display the package dependencies in openacs since this question was of importance for our upgrade.

Analyzing the dependencies on branch oacs-5-1 resulted in some issues that I think we need to fix in CVS:

  1. <h3>Obsolete package dependencies in openacs-4</h3>
    This means that we have packages under openacs-4/packages that require obsolete packages under openacs-4/contrib/obsolete-packages.
    • acs-workflow required by:
      • cms
      • glossary
    • acs-content required by:
      • spam
      • site-wide-search
    • acs-util required by:
      • cms-news-demo

    So either we kick out those packages that require obsolete packages or put the obsolete packages back to openacs-4/packages.

  2. <h3>contrib/package dependencies in openacs-4</h3>
    This means that we have packages under openacs-4/packages that require packages under openacs-4/contrib/packages.
    • bcms required by:
      • simulation
    • jabber required by:
      • jabber-portlet

    So this has to get fixed as well.

  3. <h3>Unknown package</h3>
    I was not able to find the these packages under openacs-4.
    • ui required by
      • recruiting
      • dotlrn-recruiting
  4. <h3>Typo</h3>
    This happens if users create *.info files manually or simply have a typo:
    • research-portlet requires attachmens instead of attachments
  5. <h3>Missing dependencies</h3>
    This subject goes beyond my knowledge of OpenACS and requires a study of the data model and cross reference calls of procs inside the packages. But I believe that many packages have not listed all the dependencies they have. A simple but not sufficient proof is the fact that there are only few dependencies to acs-content-repository. Also not all packages depend on acs-kernel directly or indirectly.

    How can we deal with that issue? Any idea how we could automatically generated those dependencies?

Maybe the OCT is interested to deal with the above issues?

Finally we have created graphical representations of the packages dependencies. Three version are available:

  1. Full Version
  2. Without acs-kernel - dependency to acs-kernel creates too much noise.
  3. Without dotlrn-*, *-portlet - even less noise, best usable version - IMHO.

I hope you find them helpful. Maybe someone can commit that to the documentation.

In the meantime we will integrate that process with OpenACS and commit it to CVS.

Greetings,

Nima

Collapse
Posted by Malte Sussdorff on
Hi Nima, thanks a lot for the visualisation. This is really useful.

I have one note though. I think we have too many dependencies than too few (besides our need of fixing the issues mentioned above). Any package that has dotlrn as a dependency does not have to have acs-content-repository or acs-kernel as dotlrn already depends on them through user-profile and acs-service-contract.

On the other hand, we might depend on a higher version of the acs-content-repository than dotlrn requires, this has to be explicitly stated then with each package. But I guess we are fairly fine in the #5 area you mentioned.

Collapse
Posted by Nima Mazloumi on
That's true. Only direct package dependencies should be declared.

I also found out that I missed out some packages since they are not under oacs-5-1 branch: lors, lorsm, dotlrn-lorsm, lorsm-portlet for instance.

Collapse
Posted by Orzenil Silva Junior on
Thank you, Nima, for your investigative work.

I tried find ui package in cvs looking at several branches and i think this package was really removed (or it never was initiate in cvs).

I really want try recruiting package for dotlrn so i find this cvs log in xarg.net -

http://xarg.net/tools/cvs/change-set-details?key=1497 -

showing packages/recruiting/tcl/table-sorter-procs.tcl was removed and table ui stuff was moved to new standalone ui package. But there are no logs for ui package commits.

I don't know it is a good idea but as i need a start point to a recruiting package i found an old file for table-sorter-procs.tcl in

http://cvs.openacs.org/cvs/openacs-4/packages/recruiting/tcl/Attic/table-sorter-procs.tcl?rev=1.1&view=markup

then I rename this file to packages/recruiting/tcl/recruiting-ui-procs.tcl and modified it to put recruiting installing on dotlrn-2-1 avoiding dependencies on ui package. It worked well so i uploaded the files i changed to

https://openacs.org/storage/file?file%5fid=243058

I did not create a patch for it yet because i think i could hear from people maintaining recruiting if ui package will be live in cvs.

Collapse
Posted by Jade Rubick on
Orzenil: if it's in the attic, it's either been removed, or it exists on a different branch. That could be the problem.
Collapse
Posted by Orzenil Silva Junior on
Jade: in fact table-sorter-procs file was really removed (as showed by http://cvs.openacs.org/cvs/openacs-4/packages/recruiting/tcl/Attic/table-sorter-procs.tcl?only_with_tag=HEAD) but recruiting and its dotlrn portlet and applet needs table:: from table-sorter to render tables for output then I just rewrite table-sorter-procs declaring new tcl namespace called ui. Maybe it is not necessary because i think acs-templating could deal with table-sorter-procs requirements so we could avoid ui package dependencies without reintroducing table-sorter-procs but i was in a hurry to get recruiting work just to see what it does.

Thank you for your advertisement.