Skip to content

Conversation

@akritkbehera
Copy link
Collaborator

#Description:

  • Auto-detect WORK_DIR: init.sh now automatically calculates WORK_DIR relative to its location. This allows the script to be sourced directly without manually exporting WORK_DIR beforehand.
  • Post-relocate hook: Added support for executing etc/profile.d/post-relocate.sh (if present) after the standard relocation step. This enables custom post-installation fixups for packages (skipped for defaults-* packages).

@akritkbehera akritkbehera marked this pull request as ready for review January 6, 2026 08:24
@akritkbehera akritkbehera requested a review from smuzaffar January 6, 2026 08:30
' WORK_DIR=$(realpath "${BASH_SOURCE[0]:-$0}" | sed "s|/$BITS_ARCH_PREFIX.*||")',
' export WORK_DIR',
'fi',
])
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@akritkbehera , as the new relocation logic can relocated init.*sh files so why not use
WORK_DIR=<build/work/directory> . the relocation can change it to WORK_DIR=<deploydirectory> ?

@ktf , what was the logic of setting WORK_DIR from outside? Can't we just hard-code it with proper relocation ?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The idea is that you do not need aliBuild to do the relocation of packages and loading of the environment, so everything related to that must work with WORK_DIR being set from the outside.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks @ktf , I understand that. But you still need some tool/script to deploy the pre-build packages and that tool will run the relocation .... right? If yes then why not just relocate init.*sh too?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

one benefit I see with setting WORK_DIR externally is that one can just symlink a pre-installed/deployed package from CVMFS in to local build area and its ${<PKG>_ROOT} will properly point to WORK_DIR/pkg-path.

I am fine with change in the PR. This will allow

  • bits/alibuild to use pre-deployed packages from cvmfs ( as bits/alibuild set WORK_DIR) by just symlinking them
  • No need to set WORK_DIR for setting up package env directly from deployed area as default WORK_DIR in packages' init file will be properly relocated

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The goal was to avoid relocation as much as possible. That way just untarring the tarballs would have given you a working environment.

…sh` if present.

pass work directory directly to `generate_initdotsh` instead of deriving it dynamically.

Test Case Fix
@pbuncic pbuncic merged commit efa666b into bitsorg:main Jan 12, 2026
12 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants