Mb2 shared output directory: allow to disable zypper distribution update

Platform Development
#21

Let’s start with the test result:

Having sb2 -t "$OPT_TARGET" -m sdk-install -R zypper "${args[@]}" in "${deps[@]}" before zypper dup and later followed with zypper in will solve my issue. In my case, the last zypper in would be no-op.

Re “dup is considered harmful in my case”:

As it is in released mb2 (before your patch or a patch allowing to disable zypper dup), resetting snapshot is insufficient in my case. If you look into details of Mb2 shared output directory: allow to disable zypper distribution update, zypper dup can install into the clean snapshot the package that will conflict with the buildrequirement package. That what happened in my case.

As with OBS, TBuilder starts with a clean snapshot and it looks to be an only sane way to ensure consistency of the environment. So, regardless to how zypper dup is resolved, I will keep it that way.

Re snapshots.snapshots and packages:

Very clever. In this case, it would be possible to use, but not from the start. Some of the preferred packages are built within that project (libhybris for example) and they fail to install at the start of the build. This failure is reported by tbuilder but considered OK and the build continues. Later, after libhybris is available, it is installed to replace Mesa libs, similar to OBS.

So, I could use your suggestion if I track the status of installation. In addition, I would have to track all packages that were installed during these operations (libhybris and all dependencies). The snapshot with these installed packages would have to be reset as soon as one of them is rebuilt for one reason or another. Which would make it non-trivial to implement, unfortunately.

#22

I still fail to clearly see how it happens that zypper dup on a clean target pulls in the unwanted package. Because something needs to require a package in order to be pulled in by zypper dup. And if we are talking about clear target…

Before you wrote

zypper dup pulls in droid-config-XXXX and, as a result, droid-system-apollo and droid-system-apollo-h8314

Which of the packages from config.yaml pulls in droid-config-XXXX as a dependency? Or which way it is required if not this way?

#23

Which of the packages from config.yaml pulls in droid-config-XXXX as a dependency? Or which way it is required if not this way?

droid-config-XXXX provide the same symbols as ofono-configs-mer and usb-moded-defaults. In fact, they obsolete these packages. As a result, configs are pulled in during zypper dup. As, in turn, they require droid-system-, the whole sequence of events starts.

PS: Just checked the logs, droid-config packages are not pulled by any of the forced-installed packages requested in the project

#24

Great, your last message made it clear I think. Based on your previous test with the in-dup-in variant, simply swapping it should be sufficient and it should work equally well in general - test please https://github.com/sailfishos/sdk-setup/pull/236.

1 Like
#25

I checked it on compilation of droid-hal-version- for 3 devices and it worked for all of them. So, in my case, this change is sufficient.

There is still some uncertainty in pulling some other packages (one other config was pulled during dup for all devices - droid-config-h8216-policy-settings), but that seemed not to interfere with the build. This aspect is somewhat concerning, but it is hopefully OK for most cases.

#26

This is now fixed in Sailfish SDK 3.6, which was released to Early Access users just a while ago.

In addition to that, sfdk now allows to alter some aspects of its operation, including build target initialization, with hooks. See HOOKS in sfdk --help-all.

1 Like