debian-installer-netboot-images source package is less than 6k in size.
Clearly the main part of the resulting binary packages come from
fetching resources over the network (apparently using wget).

Debian Policy includes the following in §4.2:
network using wget.


Kind regards,

 - Jonas

- -- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.2.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=da_DK.UTF-8, LC_CTYPE=da_DK.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
iQIcBAEBAgAGBQJWZCrtAAoJECx8MUbBoAEh/9AP/jvT+CdfkcpSd7iM81kJfXik
eckvuOlGT7yAbthtD08r7c0bXSggJRmCVo2Yw8SKJywvaCdRfXqUu74B2en2EQPi
oWOWeOTTSgDzhFyO06FcGYk4MK4EsthRJH6dUW+djOW1ovqQODfZC3uhfNwzvLjt
ygxqgDK5p4mWQOgcpHxBzclR8+LlXtu7RsXNtPEqDeIqLHr3NaKInW9nMEmm030d
PTRgw26h9qe47njlNPGgfKPYbwnZdzLLBils0429AmvRStu/OTXgLcwUkaIXs3dX
URwoCzJ8X6F3jJUZo7trX1nrkGdyCE3k2VfT9kavWxiAlvoHd4rtWaqdheHDfVW7
xJgXNZAZ8pQC4Quy09/iOTcQqIpJHd7JmZyaxzTuxf27mHdAc3SCJVd2Kx85uIft
MjGlKdt5LakMQ56NggYsbFeaEU+fyKDU46a8c79uKwK6zW7s892JJAeX0/4hTqq1
BAEueBwpzAl743jKhnwWjM5qvhn0L589WmOJ/zjsURXSmYZ4s8tYyAHN+1nB/HDZ
YUpaaJ2LeLCRTI5hdcl2V3ePTf1SXXdgSo8pXBsq5PfzUu217OZrmkBumJ+gEm/A
cTVtHFKbpYa1xcPQVLAEDnNmmSl16WIuQnlO1opUvPISFdxwTquSY5NrnpqINVoh
08U2a4CkHfyTofdKLB9t
=bP2q
-----END PGP SIGNATURE-----

Is it legal to build a unique arch:all package per architecture?

Kind regards
Philipp Kern

Le dimanche, 6 décembre 2015, 18.02:48 Jonas Smedegaard a écrit :

d-i-n-i does (it's own) trust-path checking upon download, and it's
doing so because there's (currently) no way to have these files local
through Build-Depends.

The specificity of the resulting packages is that they are arch-all
while containing arch-specific files. Their value comes from the fact
that you can install netboot images for all Debian architectures
(through arch:all packages) on any Debian architecture, without having
to add add these archs through multiarch.

So the alternative would be to build these arch:all packages in the
debian-installer build-arch target, but that wouldn't pass the incoming
processing, as far as I know, as dak currently considers that there will
be only one arch:all changes file per source.

Now talkin' crazy; we could also (ab)use byhand processing to produce
these packages on the archive side; but using the archive to produce
packages isn't really something we want to dive into.

So, the situation is known to not be Policy-compliant, but at least
there's trust-path checking. In this specific case, I value the
existance of these packages in their current form higher than Policy-
compliance, thereby tagging +wontfix. But I'm open to ideas!

What would you propose?

Cheers,
OdyX

Quoting Didier 'OdyX' Raboud (2015-12-07 12:52:26)

Thanks for clarifying.

Seems to me the underlying issue is that those parts fetched with wget
is not provided in any binary package.  Does that sound correct to you?

I have filed bug#807312 about that, and marked it as blocking this one.

 - Jonas

Correct.  And there are good reason for this.  One should be able to
build the package for another release without using that release for the
build environment.  The build process requires downloading but not
installing udebs for use in the installer, as well as debs which are
used to provide parts like glibc, kernel etc and they are not installed
but the required components extracted and mostly having the symbols
stripped (to reduce the resulting binary size) and all these parts are
assembled into the installer image.

The binary package itself is build-able in this case, but not the
installer-images for obvious reasons.  That the source package builds
the installer images in this way is likely a convenience to allow taking
advantage of the automated build systems rather then having to build and
maintain a separate system for that purpose.

Perhaps Debian Policy §4.2 should be amended to either carve out an
exception for debian installer and similar packages or a more generic
exception such that it only applies to the binary debs and not other
build artifacts.

Either that or Debian will have to implement a different solution for
building the installer images.  YMMV

Regards,
	Daniel

There is no requirement to be able to build the package for another
release than the current build environment. Now, within Debian, that's
a bit more fuzzy than it should be, but the point is that you're
supposed to build a package for the current distribution of the chroot.

I guess it's clear that the current state for both the netboot images
and debian-installer itself is suboptimal. But it's not unheard of that
certain packages need to ignore the rules for a while to eventually
become compliant. (Which might mean RC bug and *-ignore tags.)

Kind regards
Philipp Kern