Re: RFC: Patches for supporting cross-building
Hi Kazu,
On Sun, Jul 29, 2018 at 03:24:30AM +0900, Kazuhiro Hayashi wrote:
> Thanks much for telling the detailed states of the two builders.
> Regarding the current way, we also set CONFIG_SITE for dpkg-buildpackage.
> https://github.com/meta-debian/debian-cross-patches/blob/master/HOWTO.md
Beware that this howto uses the site file from src:dpkg-cross
cross-config. These site files are horribly incomplete, include a fair
amount of obsolete assignments and a fair pile of wrong assignments.
While they still are the default (and assigned by sbuild), I personally
consider them broken and don't use or maintain them in any way.
> > > 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".
> I know that Build-Depends actually has at least two kinds of dependency;
> 1. host architecture packages (e.g. development libraries to be linked) and
Build-Depends are always treated has host architecture unless noted
otherwise. There are three major ways to tell the resolver not to use a
host architecture package:
> 2. build architecture packages (e.g. commands or tools for support building).
* The dependee is marked Multi-Arch: foreign.
* The dependee is marked Multi-Arch: allowed and the dependency is
annotated :any.
* The dependee is not Architecture: all and the dependency is annotated
:native.
> "Build-Depends on perl-base" in this case is 2, I guess.
No. "Build-Depends: perl-base:any" (since perl-base is M-A:allowed) or
"Build-Depends: perl-base:native" is case 2.
> My question here is why the host architecture essential packages are discarded.
Essential packages are always assumed installed (regardless of whether
you are building packages or not). Libraries (like libc6) are not
essential themselves, but they can be transitively essential when some
other essential package depends on them. Most essential packages contain
executables, so cross grading them to host architecture would cause an
"Exec format error" in the majority of cases. Thus it is not useful to
consider foreign essential packages in an installation set. Since
libraries are only transitively essential (not directly essential), we
can still coinstall the host versions in most cases.
> What kind of package lists are you meaning the above?
When you run apt update, it downloads metadata from a mirror that
metadata mainly consists of package lists. They contain information
about which binary and source packages are available, versions,
architecture, dependencies, description and things like that. The
collective metadata is often called "package list".
If this doesn't clear up the confusion, please continue asking.
> So, the thing we need to do for fixing "missing perl-base" issues is
> to find out perl packages, which need to have ":any" but actually not,
> from Build-Depends of each package one by one?
I'm having difficulties parsing the grammar here. The essence appears
correct though: A "missing perl-base" can have multiple causes each of
which needs to be fixed in possible multiple packages. While my report
only gives one of those reasons, there also is
https://bootstrap.debian.net/cross_all.html, which gives a better
overview on dependency issues for cross compilation.
> I'd like to know an example of this kind of fixes if already exists.
For the purpose of the example, let us switch to python. For python, the
situation is quite similar. pythonX.Y-minimal is not essential (unlike
perl-base), but installing it fails postinst with an Exec format error.
The end result is the same: You cannot install a host architecture
pythonX.Y-minimal. Thus I also discard those packages from the list
prior to passing them to dose. So some examples I give are for "missing
pythonX.Y-minimal", but most of the aspects stay the same.
* #794339
* #807847
* #807849
* #840895
* #841118
* #841841
If you grep through rebootstrap tagged bugs for "unsatisfiable" you'll
likely find more.
> Yes, actually some programs (commands, daemons, etc.) were broken
> when we simply replaced essential packages by busybox,
> because of missing packages, differences in usage (e.g. available options), etc.
The key here is reducing what "essential" means. I noted that e2fsprogs
(and thus lsattr) are no longer essential. It seems that Andreas
Henriksson is working on reducing the shadow usage by moving stuff into
util-linux. He moved su into util-linux yesterday. Earlier, he split
fdisk out into a separate package. Continuing the "tinyfication" will be
an ongoing adventure.
> udeb should not be mixed with deb packages, so
> I don't have any expectation in mixing them.
> Also I know that udebs' coverage is limited, but
> it's sometime enough to implement the tiny system.
The major problem with udebs is that adding udebs is not cheap in terms
of maintainer time.
> The problem is resources for developing and testing udeb 'binary' packages
> are completely splitted from efforts for deb packages.
Exactly.
> ('source' packages are still shared)
> If Debian installer could consist of essential deb packages instead of udeb
> and their footprint become less than now, there might be benefits for
> the both of Debian community and product developers.
Indeed, that question was raised on #debian-devel recently. Given that
the size constraints on installation media is no longer that strict, it
may be possible to use regular .debs for the installer. I do note though
that no debian installer team member participated in that discussion, so
the next step would be proposing it to debian-boot@lists.debian.org. I'm
sure that the idea is not new to Cyril Brulebois and he'll know more
about the problems with the approach.
Helmut
Reply to: