@mak you wrote this in a related discussion (in a non-public chat where you gave permission to quote in public):

Laniakea can sync a specific list of packages from any suite into landing, however this is definitely not a smart idea on PureOS as it currently is. We did that mistake on Tanglu in the past. Since PureOS doesn't rebuild all packages synced from Debian, there might be subtle incompatibilities, or synced packages would just flat out not work due to dependency issues. Or the synced experimental packages would break other stuff if not rebuilt against them, GLib is a primary candidate here (but we also had DBus interface incompatibilities occasionally).
So, if we sync stuff from random suites, I would also opt for rebuilding all Debian packages for PureOS, which in turn would require us to do transitions like Debian does (which would mean people would have to monitor and do those).

Can you elaborate on what kind of "subtle incompatibilities" you consider rendering it "definitively not a smart idea" to let Debian unstable packages into PureOS?

To me it seems like that is *exactly* what PureOS is: Debian unstable packages that has been let into Debian testing and from there into PureOS - without any recompilation.

Please note that to scope of _this_ issue is purely migration of packages *WITHOUT* recompilation. You you quite welcome to also elaborate on the benefits you see in recompiling source packages but please do that at T366 instead.

Can you elaborate on what kind of "subtle incompatibilities" you consider rendering it "definitively not a smart idea" to let Debian unstable packages into PureOS?

This mostly comes down to implicit dependencies and tested configurations. E.g. a new upload of a package to unstable might work in the context of Debian unstable because it was compiled there e.g. with a specific version of LLVM that has certain bugs fixed, while it would break in the Debian testing based context of PureOS.
This gets even more annoying when we do binary syncs where we actually might pull in dependencies on packages that don't exist in PureOS yet (I expect that to be really frequent, while the other category of bugs is more rare and subtle).
When Debian unstable is in active development with transitions going on in unstable, I would even assume we wouldn't be able to selectively sync 90% of the packages without introducing some kind of dependency issue. Most packages don't have a symbols file afterall to limit binary package library dependencies.
So, if we would sync stuff from unstable onto our testing-based OS, we *must* at least rebuild the packages.

Sorry, I don't follow what is so definite. Why do we not - by the exact same logic - "definitely" need to rebuild all the packages that we grab from testing?

Attempting a sync, seeing it fail and then needing to do a manual rebuild is not efficient and can not be reliably automated. Attempting a sync which works but has a decent chance of introducing breakage which can be avoided by a rebuild is not wise.
By always rebuilding packages synced from foreign suites we get a 100% automatable process that saves human work and avoids the introduction of errors due to binaries being built in the wrong environment, even if they are rare.

Rebuilding sure avoids some (possibly gazillions) edge cases. This issue is about something else, though:

This issue is about allowing packages from Debian unstable - which would have auto-migrated if not flagged to stay out of testing.

I am still puzzled how such packages can "definitely" not get included without rebuilding.

Just FTR, we can't binary-sync anything from experimental, ever. Packages there are built with other binaries from experimental, which would break any suite we sync them into. Source syncs can work though, but will need support implemented in Synchrontron in Laniakea.

Issue description updated to not mention experimental.