Small fix, rewrite the Package builds section

This MR:

• removes the use of snapshotted
• rewrites the Package builds section adding more details about package builds using the SDK, devroots and snapshots of APT archives. It mentions the differences between building on OBS and on the SDK and differences between native and emulated builds.

content/architecture/long-term-reproducibility.md

@@ -137,7 +137,7 @@ but not exactly the original one gives acceptable results.
 To further make build environments more reproducible, care can be taken to
 make their own build process as reproducible as possible.
 The same concerns affecting the main build recipes affect the recipes for the
-Docker images, from storing pipelines in git, to relying only on snapshotted
+Docker images, from storing pipelines in git, to relying only on snapshots of
 package archives, to taking extra care on third-party downloads, and the
 following sections address those concerns for both the build environments
 and the main build process.
@@ -216,12 +216,12 @@ While the stability of the release channels is suitable for most use-cases,
 sometimes it is desirable to reproduce an old build as close to the
 original as possible, ignoring any update regardless of their importance.
 
-To accomplish that goal the package archives are snapshotted regularly,
-storing their full history. The image build pipeline accepts an optional
-parameter to use a specific snapshot rather than the latest contents.
-This results in the execution installing exactly the same packages and
-versions as the original run, regardless of any changes that landed in the
-archive in the meantime.
+To accomplish that goal snapshots of the package archives are created
+regularly, storing their full history. The image build pipeline accepts an
+optional parameter to use a specific snapshot rather than the latest contents.
+This results in the execution installing exactly the same packages and versions
+as the original run, regardless of any changes that landed in the archive in
+the meantime.
 
 To use a snapshot it is sufficient to change the APT mirror address, for
 instance going from `https://repositories.apertis.org/apertis/` to
@@ -308,14 +308,55 @@ the remaining planned improvements.
 
 ## Package builds
 
-Package builds happen on OBS which does not have snapshotting capabilities and
-always builds every package on a clean, isolated environment built using the
-latest package versions for each channel.
+Apertis uses [OBS](https://openbuildservice.org/) for building packages,
+however since the purpose of the long term reproducibility does not involve
+large scale package rebuilds, we recommend using the [Apertis
+SDK]({{< ref "software-development-kit.md" >}}) for building packages. In addition to
+the SDK a [devroot]({{< ref "sysroots-and-devroots/#devroot" >}}) and a snapshot
+of the APT repositories are also required.
 
-Since the purposes taken in account in this document do not involve large scale
-package rebuilds, it is recommended to use the SDK images and the devroots in
-combination with the snapshotted APT archives to rebuild packages in an
-environment closely matching a past build.
+We recommend the SDK release to match the release of Apertis in the target
+device, and it is important that both the release and architecture of the
+devroot and of the snapshot of the APT repositories matches the target device.
+As an example, if the target is an `ARM64` device, the devroot and the snapshot
+of the APT repositories should also be for `ARM64`.
+
+See the [devroot]({{< ref "sysroots-and-devroots/#devroot" >}}) for more
+information.
+
+For the long term reproducibility we recommend the product team to have a
+backup copy of:
+ * The Apertis SDK: Matching the Apertis release in use by the target device.
+ * The Apertis devroot: Matching the Apertis release and the architecture of
+   the target device.
+
+At the time of writing OBS supports native and emulated builds, and we have
+successfully deployed emulated builds on the Bosch Developer Cloud. While
+emulated builds are expected to work in most cases, they may require
+changes to the packages being build using emulation, and they may produce
+different results when compared to native builds.
+
+For more information about emulated and native builds see
+[Build infrastructure on Intel x86-64]({{< ref "x86-build-infrastructure.md" >}}).
+
+Building packages on the SDK uses emulation, and while this approach is
+currently expected to be satisfactory, it may produce different results when
+compared to native builds. In the unlikely event of emulated builds not being
+satisfactory, we describe a mitigation on the section Future work on package
+builds.
+
+### Future work on package builds
+
+We recommend using the Apertis SDK for building packages in the context of the
+long term reproducibility to enable product teams to build packages without
+depending on custom OBS deployments.
+
+However using OBS for building packages in the context of the long term
+reproducibility may offer advantages, when large package rebuilds are needed or
+when native builds are required.
+
+We will consider for future work automating the OBS configuration to support
+building packages for the long term reproducibility.
 
 # Recommendations for product teams
 
@@ -357,7 +398,7 @@ contents available from the package archive.
 
 The most common approach, also employed in Debian upstream, is to take
 snapshots of the archive contents so that subsequent builds can point to the
-snapshotted version and retrieve the exact package versions originally used.
+snapshot and retrieve the exact package versions originally used.
 
 To provide the needed server-side support, the archive manager need to be
 switched to the `aptly` archive manager as it provides explicit support for
@@ -484,7 +525,7 @@ In this way the product team has complete control on the components used to
 build their products:
 * Source code for all packages is stored on GitLab with full development
   history
-* Compiled binary packages are tracked by the APT archive snapshotting system
+* Compiled binary packages are tracked by snapshots of the APT archive system
   for both the product-specific packages and the packages in the main Apertis
   archive.