Page MenuHomePureOS Tracker

PureOS is too stable when auto-migrating only from Debian testing
Open, HighPublic

Description

PureOS generally tracks Debian testing.

Debian testing is a staging area for Debian stable, but PureOS reuse that as a rolling-release instead.

Some packages in Debian unstable could technically migrate as-is (i.e. WITHOUT recompilation!) but is kept out for "political" reasons - e.g. because the package is deemed unsuitable for Debian stable.

Similarly, some packages in Debian experimental are placed there not because they are horribly dangerous, but because of "political" reasons - e.g. to not clutter Debian unstable during release process.

Sometimes PureOS could benefit from auto-including as-is (i.e. WITHOUT recompilation!) such "political refugees" that might be unsuitable in Debian stable but would be suitable for an imaginary Debian testing-but-repurposed-as-a-rolling-release.

Therefore: Please extend PureOS infrastructure to emulate the Debian unstable-to-testing migration routines, and apply such routines to try include into PureOS landing exceptionally listed single packages from Debian unstable and Debian experimental.

NB! This issue is *NOT* about auto-compiling packages source-identical to unstable or experimental packages. Please see T366 for that.

Event Timeline

jonas.smedegaard renamed this task from PureOS is too stable when auto-including prebuilt packages only from Debian testing to PureOS is too stable when auto-migrating only from Debian testing.Mar 18 2019, 09:24

@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.

mak added a comment.Apr 14 2019, 14:24

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?

mak added a comment.Apr 14 2019, 14:41

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.