Spack updates (e.g. 0.19.0 to 0.19.2)

[Masshardt, Eric]

If we have spack versions like X.Y.Z, are all the .Z updates bug fix updates and .Y updates feature updates?

 

If the .Z's are just bug fix updates, I'm wondering if one can update the base spack version in place (e.g. 0.19.0 to 0.19.[1|2]) and, if so, what's the best way to do this (git pull, git clone)?

 

Thanks!

[Davide DelVento]

My understanding is that the answer to this question is no, you can never do that "in place" but always have to start from scratch (which on a production system is what I'd do anyway, by creating a separate install tree and module path so that I can first throughout test everything before releasing to users)

--
You received this message because you are subscribed to the Google Groups "Spack" group.
To unsubscribe from this group and stop receiving emails from it, send an email to spack+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/spack/CO1PR17MB5322C3545F6787294B6F2F03FA649%40CO1PR17MB5322.namprd17.prod.outlook.com.

[Todd Gamblin]

Yep, this is how it’s supposed to work.  We don’t backport package changes to these branches so pulling on the release branch will not disturb your stacks.  You should be able to update in place.

See here for more details: https://spack.readthedocs.io/en/latest/developer_guide.html#releases

-Todd

[Richard Young]

In our configuration of spack, the modules and software directories are configured to be outside the spack software tree. So, when an update of spack is to be installed, its downloaded and placed in its version number, e.g. spack-0.19.0, and not in just spack. As config.yaml, modules.yaml and packages.yaml have been modified to suit our requirements, they are copied/incorporated into the new version. This results in the re-use of the module and software directories. As the module command is configured to use the correct software tree, users don’t know or need to know if spack has been upgraded. The only difference is when installing new software, the correct setenv file must be sourced. This saves having to rebuild all the installed software.

 

Regards

---------------------------------------------------------------------

Richard A. Young

T: +61 7 4631 5557  |  M: +61 437 544 370

E: richar...@usq.edu.au   

Office of Research | Research and Innovation Division

---------------------------------------------------------------------

To view this discussion on the web visit https://groups.google.com/d/msgid/spack/DA01539D-941D-47EF-97C9-068BD0822A30%40gmail.com.

__________________________________________________________________

This email (including any attached files) is confidential and is 

for the intended recipient(s) only. If you received this email by 

mistake, please, as a courtesy, tell the sender, then delete this 

email.

The views and opinions are the originator's and do not necessarily 

reflect those of the University of Southern Queensland. Although 

all reasonable precautions were taken to ensure that this email 

contained no viruses at the time it was sent we accept no 

liability for any losses arising from its receipt.

The University of Southern Queensland is a registered provider 

of education with the Australian Government.

(CRICOS Institution Code QLD 00244B / NSW 02225M, TEQSA PRV12081)

[David Magda]

There’s a thread from a few years back on updating Spack:

https://groups.google.com/g/spack/c/UXXjdw9ITkE

It seems that if a site wants stability, the best way would be to do a ‘git clone’, potentially in a versioned directory (e.g., /opt/spack-0.19), and choose a particular branch, and then follow that branch (with ‘git pull’), with package installation going into a particular area (e.g., /pkgs, /apps, etc).

When there’s a new 0.x.0 release of Spack the site can create a new directory (/opt/spack-0.20) and do a new ‘git clone' for the new release branch and start using that (copying over the configuration): when pointed to the existing installation area (/apps) the new Spack release should be smart enough to detect all the existing software from the previous Spack release.

__________________________________________________________________

email.

To view this discussion on the web visit https://groups.google.com/d/msgid/spack/SYCPR01MB481402E3EBD3070CF14DB04CCE649%40SYCPR01MB4814.ausprd01.prod.outlook.com.

[mart...@gmail.com]

We do what Richard and David describe as well - install new versions of Spack to their unique dirs, and bring the configs from the previous version. This has worked OK most of the time, but, I noticed that between v. 0.17.2 and 0.19.0 there were a few API changes to the package def Python modules, which caused our custom package specs to break. After removing these custom package specs, Spack "spec", "install", etc, started to complain about missing specs (from the custom specs) - because they are listed in .spack-db. After a long debate on what's the best solution to work around this, we ended up making a separate repos and builds directories for each major release, but kept the modules at the same location, so in essence with Spack update we build newer packages, but older packages that have been built by the older Spack version stay in the older version's build directory and are being pointed to by their modules. So, from the user's perspective, nothing changes, from the builder's perspective, one needs to build a new set of dependencies for the new version of the package built with the new version of Spack.

For our own sake, I have Spack update instructions listed at https://github.com/CHPC-UofU/spack-config#update-instructions.

Martin