> I suspect I will eventually apply the changes, but it is a bit
> overwhelming for me to consider this late in the bullseye development
> cycle...
> On the other hand, it might be nice to get this in now, to avoid great
> divergence between bullseye and bookworm, should we ever need to make
> changes during the stable release cycle of bullseye...
No opinion. I was assuming the changes would go to experimental.
> > diff --git a/debian/control b/debian/control
> > index 6f4cc17906..ff3e528e50 100644
> > --- a/debian/control
> > +++ b/debian/control
> > @@ -47,7 +47,9 @@ Description: A boot loader for embedded systems
> > intended to be easy to port and to debug, and runs on many
> > supported architectures, including PPC, ARM, MIPS, x86, m68k,
> > NIOS, and Microblaze.
> > - ${uboot:platforms}
> > + .
> > + Included platforms:
> > + ${u-boot:platforms}
>
> These changes are unrelated to restructuring the package. Please drop
> them for now and/or submit separatelty. I've considered changes like
Package-specific substitution variable names are motivated by the
overall change because they allow gencontrol to be executed only
once. The only other way I can imagine to show each executed action is
one more ugly Make loop calling dh_gencontrol on each package, with an
ugly Make test on notools…
> this in the past, though left them out... one reason is "u-boot"
> contains no target platforms on armhf, for example, although at this
I can remove the generated paragraph when the list is empty, but I
don't understand your point. An empty list is at least as useful and
informative as a non-empty list.
> point it might be worth dropping the "u-boot" package on armhf.
You seem to imply that there are benefits to an empty package?
> > # Select the subarchs for DEB_HOST_ARCH
> > all_subarchs := $(shell dh_listpackages --arch --no-package=u-boot-tools)
> > -# DEB_BUILD_PROFILES=pkg.uboot.subarch.SUBARCH may
> > -# limit builds to only certain subarchitectures
> > -# e.g. pkg.uboot.subarch.rockchip will only build rockchip targets.
> > -ifeq (,$(filter pkg.uboot.subarch.%,$(DEB_BUILD_PROFILES)))
> > - built_subarchs := $(all_subarchs)
> > -else
> > - built_subarchs := $(patsubst pkg.uboot.subarch.%,u-boot-%,$(filter
> > pkg.uboot.subarch.%,$(DEB_BUILD_PROFILES)))
> > -endif
> > +# This variable is intended for command line override:
> > +built_subarchs := $(all_subarchs)
> >
> > %:
> > # The -N options prevents a lots of warnings about obviously missing
> > files.
> How is this to be used with, say, sbuild?
I am not using sbuild, so I fail to guess the implicit part of your
question.
If the problem is to pass options to debian/rules, this seems possible
with something like:
# sbuild '--debbuildopt=--rules-file=debian/rules built_subarchs=S'
Similar options could be documented for
dpkg-buildpackage/pbuilder/whatever.
If the problem is that sbuild requires all .debs listed in
debian/control built even empty, it is trivial to remove -N. I have
only added it in order to silent some debhelper warnings.
Build profiles are intended for parametrization of debian/control.
For debian/rules, command line options are far more flexible.
As far as I know, a proper solution would require either an horrible
debian/control:
Package: u-boot-amlogic
Build-Profiles: <!pkg.uboot.subarch.rockchip !pkg.uboot.subarch.sunxi ..>
Package: u-boot-rockchip
Build-Profiles: <!pkg.uboot.subarch.amlogic !pkg.uboot.subarch.sunxi !..>
...
or horrible values for DEB_BUILD_PROFILES:
Package: u-boot-amlogic
Build-Profiles: <!pkg.uboot.noamlogic>
Package: u-boot-rockchip
Build-Profiles: <!pkg.uboot.norockchip>
...
You have choosen not to implement these solutions.
My understanding is that the use cases are limited to
* local build for immediate installation on a given hardware
* test build before a commit
but no cross or bootstrap issues on buildds.
Is this right?
