1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
|
Usually upstream releases the source packages src:pico-sdk and src:picotool
together in lockstep with the same version. To build most things with pico-sdk
you also need a picotool of at least that version. But building with picotool
(even though not very useful for most use-cases) can be disabled by setting
PICO_NO_PICOTOOL=ON in the cmake flags. To avoid a circular dependency between
the two source packages we do the following:
pico-sdk gets compiled with PICO_NO_PICOTOOL=ON to make sure that the sdk can
be built. Building with reduced functionality is no problem, because the
resulting binaries are not getting distributed. Instead, the pico-sdk-source
package ships source code in /usr/src/pico-sdk. Even though most uses of
pico-sdk-source need picotool, the pico-sdk-source package does not depend on
picotool -- it only recommends it. A hard dependency is not required because
technically (when building with PICO_NO_PICOTOOL=ON), pico-sdk-source can be
used just fine without picotool. Having picotool as a Recommends only is
required to not prevent building the new picotool.
The src:picotool source package cannot be built without the pico-sdk-source
build dependency of at least the same version. If the pico-sdk-source would
Depends instead of Recommends on picotool, then packaging new versions of
picotool would be made tricky and would require a bootstrapping step.
Since building with pico-sdk-source requires a recent-enough picotool, the
src:pico-sdk source package does not come with an autopkgtest to build
something with pico-sdk-source. If it would, that autopkgtest would fail when
compiling new versions of src:pico-sdk because the autopkgtest would need a
version of picotool that is at least as high as the version of src:pico-sdk and
that version cannot get uploaded to the archive before pico-sdk itself gets
uploaded. We want to avoid uploading pico-sdk with a failing autopkgtest. So
the test to compile a very small project using pico-sdk-source is in the
picotool source package.
So the order of packaging new versions of src:pico-sdk and src:picotool is the
following:
0. (optional) package potentially new version of tinyusb
1. package the new version of pico-sdk
1.1 bump Recommends of picotool to the new version
2. upload the new pico-sdk version and wait for the next dinstall with it
3. while waiting, package the new picotool
3.1 bump Build-Depends on pico-sdk-source to the new version
3.1 bump Depends of the autopkgtest to the new pico-sdk-source version
4. upload picotool to unstable after it was built and its autopkgtest ran
successfully with the new pico-sdk in the archive
|
