Jb54117 #236
Jb54117 #236
Conversation
…ixes JB#54117 The original order of zypper invocation becomes an issue when the capability is also provided by some of the packages installed by default. In this case `zypper dup --from` choices randomly which of the locally provided packages should be pulled in and replace the one available before/by default.
| # the output directory as the repos may contain newer packages and | ||
| # those would be pulled in preferably. This happens not only when | ||
| # working with older sources but also when a package hardcodes | ||
| # version in its spec and the --fix-version option is not active. |
There was a problem hiding this comment.
Now this seems so logical that I'm starting to wonder if there was some reason (that I'm not aware of and you have already forgotten) why dup was originally performed before install?
There was a problem hiding this comment.
Yeah, seems logical but it feels more natural/safe to dup first and install new packages later - this is what you would normally do to your system, right? In theory, ordered install-first it could fail temporarily and there is the possibility to get a package pulled from a regular repo first and downgraded to the local built version in a second step - harmless but slightly annoying.
|
There is a demand for another feature we discovered yesterday: optionally preinstall additional (not build-required) packages into a temporary snapshot. Optionally == do not fail when they do not exist as they may be provided locally later. Instead of making this a built-in feature of mb2, I would like to add a generic mechanism that would allow freely tweaking the temporary snapshots. This would also allow completely overriding the way build requires all pulled in. |
No description provided.