Upgrading 3.3.12+ to 3.4

These instructions help you upgrade EPrints 3.3.12+ to 3.4 while keeping all your eprints, documents and local configuration changes.

It assumes your EPrints 3.3.12+ was installed using a tarball (tar.gz) file and installed in /opt/eprints3. The commands in these instructions assumes Centos 7 OS and run as the eprints user, unless it stated to run as root user.

Upgrade from Tarball

Pre-upgrade

• If you have local modifications to the core files (in /opt/eprints3/perl_lib), you may need to manually migrate your changes.
• If you use Twitter integration, use CPAN to install LWP::Authen::OAuth as this is no longer in perl_lib.

as root:

cpan LWP::Authen::OAuth

• Note down the enabled bazaar package on your repository.
• Make a backup of your local configs.

Process

We will move your existing eprints 3.3.12+ installation from /opt/eprints3/ to /opt/eprints3.3, install eprints 3.4, then migrate your configurations into EPrints 3.4. as root:

apachectl stop
cd /opt
mv eprints3 eprints3.3

• Download EPrints 3.4 core and publication flavour tarball and install them Files.eprints.org

as root:

cd /root
tar xvzf eprints-3.4.0-rc1.tar.gz
tar xvzf eprints-3.4.0-rc1-flavours.tar.gz
cd eprints-3.4.0
./configure
make install

• Move your current repository from 3.3 to 3.4

as root:

cd /opt
mv eprints3.3/archives/ARCHIVENAME eprints3/archives/
After moving, make sure all files inside /opt/eprints3 are still owned by eprints user and belongs to eprints group.

• In /opt/eprints3/archives/ARCHIVENAME/, create cfg/cfg.d/00_flavour.pl and set the appropriate flavour, typically 'pub':

$c->{flavour} = 'pub';

• create a symbolic link to default.xml

cd /opt/eprints3/archives/ARCHIVENAME/cfg/templates/ (or /opt/eprints3/archives/ARCHIVENAME/cfg/lang/en/templates/
ln -s default.xml default_internal.xml

• Audit each of their local config files against the pub_lib flavours config files. The first Diff below will identify all the files that are the same. If so delete the ones in archives/ARCHIVENAME/cfg/cfg.d/. There is a good chance you will not find any. The second diff will find where files exists in both directory are different. Here they should be compared to see if the local differences are superficial (e.g. slightly different comments or spacing) and therefore can be removed. Also the pub_lib flavour version may fix an outstanding bug or perform the required functionality more succinctly. If this is the only change then the local archive version can be deleted otherwise the change should be incorporated in the local version.

cd /opt/eprints3/
diff -rs archives/ARCHIVENAME/cfg/cfg.d flavours/pub_lib/cfg.d | egrep '^Files .+ and .+ are identical$'
diff -rq archives/ARCHIVENAME/cfg/cfg.d flavours/pub_lib/cfg.d | egrep '^Files .+ and .+ differ$'

• Compare archives/ARCHIVENAME/cfg/cfg.d/eprint_fields.pl with flavours/pub_lib/cfg/cfg.d/eprint_fields_pub.pl,
  • If these are different and fields are present in eprint_fields_pub.pl and not eprint_fields.pl or the definitions (e.g. type, options, etc.) for the same field are different then:
    1. Copy flavours/pub_lib/cfg.d/eprint_fields_pub.pl to their archive's cfg/cfg.d/
    2. Modify the fields in their archive's cfg/cfg.d/eprint_fields_pub.pl where they have different definitions (e.g. type, options, etc.) to those in eprint_fields.pl
    3. Remove all fields in their archive's cfg/cfg.d/eprint_fields.pl where they also occur in their archive's cfg/cfg.d/eprint_fields_pub.pl
  • If there are only additional fields in archives/ARCHIVENAME/cfg/cfg.d/eprint_fields.pl then just do the last step.
  • If the two files are identical then you need to nothing. However, this is extremly unlikely.

• As the eprints user, run epadmin update to add any new fields that were not previously present (typically this is embargo_reason for documents and requester_email for request)

/opt/eprints3/bin/epadmin update ARCHIVENAME

• Generate Apache configuration and as root test (fixing any issues) and restart Apache.

/opt/eprints3/bin/generate_apacheconf --system --replace

as root:

apachectl configtest
apachectl restart

• Once confirming that EPrints is generally working. Go to Admin-> Bazaar then install the required bazaar packages. Ensure the following bazaar files are disabled by renaming to FILENAME.pl.disabled. Once they have been reinstalled via the Bazaar then they can be moved back into place:

mv z_orcid_support.pl z_orcid_support.pl.disabled
mv zz_hefce_oa_fields.pl zz_hefce_oa_fields.pl.disabled
mv zz_rioxx2.pl zz_rioxx2.pl.disabled
mv z_meprints.pl z_meprints.pl.disabled 

• Finally, run generate statics to make sure all pages are regenerates with any changes to configuration.

 /opt/eprints3/bin/generate_static ARCHIVE_NAME

Notes

• 3.4 does not automatically update an archive's html/en/ files. If there are any bugs with broken Javascript or unexpected CSS, try deleting the archives html/en/javascript/auto.js or html/en/style/auto.css. Similarly if a static page cannot be changed try deleting it under the archive's html/en/ or running generate_static.
• If some perl modules are giving out error message like:

 Can't locate object method "new" via package "EPrints::Plugin::Event::PIRUS" at /opt/eprints3/bin/../perl_lib/EPrints/PluginFactory.pm line 276.
 Can't locate object method "new" via package "EPrints::Plugin::Screen::EPrint::Box::Tools::SUPER" at /opt/eprints3/site_lib/plugins/EPrints/Plugin/Screen/EPrint/Box/Tools.pm line 12.

It is because their parent module has not been initialised. This happens when the parent module lives in perl_lib, and the problem module live in elsewhere e.g. parent module of PIRUS(Event.pm) is in perl_lib, while the PIRUS.pm is in pub_lib. Just need to "use" the parent module before the ISA line:

use EPrints::Plugin::Event;