Skip to content

Conversation

@mgondan
Copy link
Contributor

@mgondan mgondan commented Oct 17, 2024

I think the order is in the wrong way. Say, pack a depends on pack b, and both have post-installation scripts. Then, pack b's script should be run before pack a's script. This does not seem to be the case here. If I reverse the order, it is running fine.

There's probably a better way to fix this (e.g., in build_order).

I think the order is in the wrong way. Say, pack a depends on pack b, and both have post-installation scripts. Then, pack b's script should be run before pack a's script. This does not seem to be the case here. If I reverse the order, it is running fine.

There's probably a better way to fix this (e.g., in build_order).
JanWielemaker added a commit that referenced this pull request Oct 18, 2024
Based on #1326, but fixing build_order/2 rather than reversing afterwards.
@JanWielemaker
Copy link
Member

Thanks. Should be fixed with 1cf4acb, which changes build_order/2.

@mgondan
Copy link
Contributor Author

mgondan commented Nov 4, 2024

I am a bit unsure if I am doing everything correct, but on my system, the build order hasn't changed :-/

@JanWielemaker
Copy link
Member

Do you happen to have a test case?

@mgondan
Copy link
Contributor Author

mgondan commented Nov 4, 2024

pack_install(interval).

It's a bit special since its dependency connects to R, but you see the build order before the installation (that currently fails).

% Contacting server at https://www.swi-prolog.org/pack/query ... ok
The following packs have post install scripts:
  Build interval in directory /home/gondan/.local/share/swi-prolog/pack/interval
  Build rologpp in directory /home/gondan/.local/share/swi-prolog/pack/rologpp
Run scripts? Y/n?
% Building pack interval in directory /home/gondan/.local/share/swi-prolog/pack/interval <<<<<< rologpp should have come first
-- The C compiler identification is GNU 13.2.0
-- The CXX compiler identification is GNU 13.2.0

@JanWielemaker
Copy link
Member

Ok. This one now works fine. The previous patch on this was wrong, but it did reverse the order. I suspect that the reverse (implemented as a swap of the edge directions) was the incorrect fix, possibly for some other problem. I'm pretty convinced this part of the logic is now correct (and always was), so if a new problem arises we must carefully analyse it.

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.

2 participants