You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In McStas 3.4 (and McXtrace 3.2 etc.) and earlier on Deb class systems, installations would go to the installation hierarchy /usr/share/mcstas/, e.g. with location /usr/share/mcstas/3.4/, including installation binaries under /usr/share/mcstas/3.4/bin, symlinked into /usr/bin.
At the same time, package versioning was always v. 1.0, with package names containing the "McStas version", i.e.:
ii mcstas-3.4 1.0 amd64 mcstas built using CMake
ii mcstas-3.4.26 1.0 amd64 mcstas built using CMake
ii mcstas-3.4.47 1.0 amd64 mcstas built using CMake
ii mcstas-3.4.50 1.0 amd64 mcstas built using CMake
ii mcstas-3.4.51 1.0 amd64 mcstas built using CMake
rc mcstas-3.4.55 1.0 amd64 mcstas built using CMake
rc mcstas-3.4.56 1.0 amd64 mcstas built using CMake
rc mcstas-3.4.68 1.0 amd64 mcstas built using CMake
ii mcstas-3.5.1 1.0 amd64 mcstas built using CMake
3.5.1 and later
All together, this means that with the new "standard location" there can only be one "global" McStas version installed:
binaries go to /usr/bin
"resources" go to /usr/share/mcstas/resoources
"tools" go to /usr/share/mcstas/tools
and so forth.
This unfortunately means that with 3.5.1 installed on a system, requesting 3.5.12 to be installed will mean a package conflict:
dpkg: error processing archive mcstas-3.5.12-deb64.deb (--install):
trying to overwrite '/usr/bin/mcstas', which is also in package mcstas-3.5.1 1.0
dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
Selecting previously unselected package mcstas-clustertools-3.5.12.
Preparing to unpack mcstas-clusterscripts-3.5.12-deb64.deb ...
Unpacking mcstas-clustertools-3.5.12 (3.5.12) ...
Selecting previously unselected package mcstas-comps-3.5.12.
Preparing to unpack mcstas-comps-3.5.12-deb64.deb ...
What to do - long term and short term
Once we have official Debian packages fully in place this should all be handled automatically, however in the interim we probably still need to update the CMake tooling (and mkdist?) to
Implement package names without the version tag
Use the version tag for the CPack packaging
Implement use of CPACK_DEBIAN_PACKAGE_REPLACES to let a new package replace any existing, older, installed package.
The text was updated successfully, but these errors were encountered:
Prior to McCode 3.5.1
In McStas 3.4 (and McXtrace 3.2 etc.) and earlier on Deb class systems, installations would go to the installation hierarchy
/usr/share/mcstas/
, e.g. with location/usr/share/mcstas/3.4/
, including installation binaries under/usr/share/mcstas/3.4/bin
, symlinked into/usr/bin
.At the same time, package versioning was always v. 1.0, with package names containing the "McStas version", i.e.:
3.5.1 and later
All together, this means that with the new "standard location" there can only be one "global" McStas version installed:
/usr/bin
/usr/share/mcstas/resoources
/usr/share/mcstas/tools
and so forth.
This unfortunately means that with 3.5.1 installed on a system, requesting 3.5.12 to be installed will mean a package conflict:
What to do - long term and short term
Once we have official Debian packages fully in place this should all be handled automatically, however in the interim we probably still need to update the CMake tooling (and mkdist?) to
CPACK_DEBIAN_PACKAGE_REPLACES
to let a new package replace any existing, older, installed package.The text was updated successfully, but these errors were encountered: