[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFC: Patches for supporting cross-building

Hi Kazuhiro,

On Mon, Jul 02, 2018 at 07:35:47PM +0900, Kazuhiro Hayashi wrote:
> Thanks, helpful report for us to know what's going on.
> Regarding the build environment, as the first step,
> I guess it's better to have the similar build environment as yours locally,
> properly recognize the issues you are facing in your reply to Baurzhan,
> then consider the next action.

I think there are two standard build environments. One is sbuild and the
other is pbuilder. Once either is set up for native building, cross
building is (in theory) a single flag away. For sbuild, it is --host and
for pbuilder --host-arch.

After that, the devil is in the detail. While pbuilder works around
#815172, sbuild does not, so most packages will need
--add-depends='libc-dev, libstdc++-dev' for sbuild. Then sbuild sets up
a CONFIG_SITE with cross-config (formerly dpkg-cross), but pbuilder
doesn't. It's not exactly clear whether that's good or bad. cross-config
lacks many assignments and at the same time it ships a fair number of
wrong ones. Both add "nocheck" to DEB_BUILD_OPTIONS, but only pbuilder
adds "nocheck" to DEB_BUILD_PROFILES. Neither adds the "cross" profile,
so you likely want --profiles=nocheck,cross for both. Both default to a
full build, but building Architecture: all packages doesn't make much
sense. You likely want --no-arch-all or --binary-arch respectively.

Personally, I use sbuild (because it supported cross building earlier).
However I explicitly disable the CONFIG_SITE stuff, because I consider
it too broken.

> Currently, we are simply try package building with dpkg-buildpackage
> enabling the target foreign architecture (armhf) in host environment.
> At least, more formal build process is required to test cross-building packages.
> e.g. Using sbuild/buildd, testing with multiple target architectures, etc.

Please read up man dpkg-architecture about nomenclature to avoid
confusing build/host/target.

> Actually, other several developers are mainly created the patches.
> When they post the patches to debian bug report,
> "Usertags=rebootstrap" is still enough to easily share our efforts.
> Also, I think "User=debian-cross@lists.debian.org" would make sense
> because it makes easier for other developer who are interested in cross-building
> to find the activities in this mailing list.

If we switch the user to debian-cross@lists.debian.org, we should also
switch tags to gain more precision. The usertag user however does not
connect the mailing list in any way. The list will not receive any
traffic due to such tagging. The user is more like an arbitrary

If switching to "user debian-cross@lists.debian.org", I propose using
the following tags:
 * "ftcbfs" for bugs about cross building a package where Build-Depends
   are cross-installable, but the build fails.
 * "cross-satisfiability" for bugs about packages that fail to satisfy
   their cross Build-Depends or that cause other packages to fail
   dependency satisfaction. For instance, when a foo needs to be marked
   Multi-Arch: foreign to be able to satisfy src:bar's cross
   Build-Depends, foo should receive a bug report with this tag.

> In my opinion, Ccing should be avoided because it might become harder
> for some newcomers like me to find key discussions about cross-building
> which are not for specific packages.

Yeah, that's a trade-off. I kinda concur as I've rarely Cced the list
for my own submissions.

> Instead, it would be great if there is a small summary somewhere
> about such preferred labels (like User and Usertags) in patch submissions.

So please use one of:
 * user debian-cross@lists.debian.org usertags ftcbfs
   0 bugs
 * user debian-cross@lists.debian.org usertags cross-satisfiability
   79 bugs
 * user helmutg@debian.org usertags rebootstrap (for general
   cross/bootstrap bugs)
   1654 bugs

But please do not use any other tagging schemes involving these users
without prior discussion.

> Some topics seem to be challenging but also important for my cases.
> Many packages in http://subdivi.de/~helmut/cross_report_20180614.html
> are unsatisfiable because of perl-base, is it related to the first topic?

That's a good question and the answer is "no". perl-base happens to be
"Essential: yes", so it always is installed for the build architecture.
When some package (transitively) Build-Depends: perl-base, it asks for
the host architecture perl. A conflict ensues. The presentation in my
report says "missing", because I discarded host architecture essential
packages from the package lists. It turns out that rather a lot of
things include transitive dependencies on perl (which happens to depend
on perl-base). In most cases, where you see such a conflict, we've got a
problem with dependencies. Requesting the host architecture perl is
usually not what you want, because you cannot run host architecture
programs, so fulfilling the request would be fairly useless: Running
perl would just result in an "Exec format error". It might seem like
perl should be marked "Multi-Arch: foreign", but that happens to be
wrong as you can integrate with perl in architecture-dependent ways via
perl extensions. Thus perl is marked "Multi-Arch: allowed" and shifts
the responsibility to decide which perl you need to the consumer. It
turns out that many consumers just say "perl" even when they need

In essence, when you see "missing perl-base", some dependency is wrong.
The difficult question tends to be "which one?".

> BTW, https://jenkins.debian.org/view/rebootstrap/ returns 404 to me,
> do I need to setup something to see it, or was the page already moved to another place?

Sorry for the typo. It's .net:
One glorious day, we might manage to move to .org.

> For example,
> 1. Applying small patches such as bug fixes, security fixes
>    which are not applied to upstream Debian
>    (We always should post such fixes to Debian or upstream,
>     but sometime we need to apply them locally until
>     the fixes are officially merged)

That can work with standard Debian workflows. Most packages use source
format 3.0 (quilt) now and adding patches there is quite easy.

> 2. Changing configure/build options to drop dependencies that
>    bring a lot which are not essential functions for the specific targets
>    (For robustness, simplifying packages list, reducing footprint, etc.)
>    Some of such customizations, of course, require dependency changing.

As you pointed out, Build-Profiles are the solution.

> 3. Changing the base system; e.g. init
>    busybox is still usable for many targets which provide
>    basic hardware controls and quite simple application only.
>    e.g. meta-debian ([4] in my last post) provides busybox based tiny RFS as well as systemd.
>    I know that such environment is no longer Debian, but
>    it still keep a lot of benefits from Debian 'source code' (e.g. security fixes).

This one will be quite hard with Debian. The major reason is not that
replacing init is hard. The reason is that packages need not declare
dependencies on essential packages. So whenever you remove any kind of
functionality from an essential package, you might break some other

Going this route means trading a lot of advantages you'd get from
Debian. Note that init is no longer essential, but init-system-helpers
now is.

>    My another interest related to this topic is that Debian installer (udeb) is also
>    using busybox based system and still keep maintained as 'Debian'.
>    I think there still be several possibilities to make use of such
>    existing efforts in embedded world, but I don't have concrete idea
>    to make good relation between the two different worlds.

I don't have any experience with reusing the installer like that. I do
caution though that adding udebs is a pretty manual process. The udeb
coverage is quite limited and adding your own udebs again means trading
a lot of advantages by diverging from Debian. Nonetheless I welcome you
reporting on this idea.

> 4. Compiling packages with CPU specific optimizations to improve performance

That's something https://wiki.debian.org/HelmutGrohne/rebootstrap is
supposed to enable. The idea behind rebootstrap is that it enables you
to build a base system (and potentially more) from source. In doing so,
you can add your own architecture to the dpkg database or tweak the
compiler defaults to arrive add a customized architecture.

I caution though that the shell script approach is quite fragile and
difficult to maintain. It becomes easier as more packages adopt pending
patches, but for creating OS images, a different approach (still using
the same principles and tools) likely is necessary. Until we get there,
forking rebootstrap for your own purposes (e.g. adding your extra
packages) likely is feasible.

> Yeah, minimizing the essential set is the most important and difficult issue.
> Also, other non essential packages (service daemon, utils, etc.) are usually appended
> into RFS then their big dependencies sometimes affect to the final footprint.

Well, there is one other approach to reducing installation sets. I've
been pondering this for a while, but I couldn't figure out good and
clear semantics yet.

A number of packages depend on other packages solely for the purpose for
configuring, upgrading or removing. For instance, a dependency on
adduser is rarely used outside maintainer scripts. Once you have your
final OS image, you likely don't need adduser anymore. It seems that
most dependencies can be classified into "real runtime dependencies" or
"configuration or installation dependencies". Similar to how we
augmented Build-Depends to Build-Depends-Indep and Build-Depends-Arch,
it might be possible to split Depends into e.g. "Runtime-Depends" and
"Maintscript-Depends". For OS images, we may be able to use DPKG_ROOT
and --force-script-chrootless and thus install those
"Maintscript-Depends" outside the OS tree being installed effectively
avoiding them in our OS image.


Reply to: