Quoting Karsten Merker (2015-11-12 21:10:42)
> On Wed, Nov 11, 2015 at 05:07:45PM +0100, Cyril Brulebois wrote:
> > Jonas Smedegaard <dr@jones.dk> (2015-11-10):
> > > I've hit a bug¹ in a non-package part of Debian, identified that it is
> > > tied to variations not in package releases but web-facing parts of
> > > official Debian:
> > > http://ftp.de.debian.org/debian/dists/stretch/main/installer-armhf/$timestamp/images/netboot/SD-card-images/
> > >
> > > I filed a bugreport against the pseudo-package seeming most appropriate,
> > > but then got no (maintainer) response for a week. That delay might be
> > > perfectly fine (I often have far worse reaction time myself), but made
> > > me wonder: Did I file it wrongly, so that the bug isn't "heard"?
> > >
> > > Which pseudo-package do ARM netboot image slices belong to?
> > >
> > > or more generally:
> > >
> > > Is there some way of verifying which pseudo-package(s) is(/are)
> > > appropriate for targeting a bugreport, when web address is known?
> > >
> > > For real packages where I have located a file involved, I can verify if
> > > a proper package is targeted by use of "dpkg -L ..." or "apt-file search
> > > ..." or similar tools. Do we have similar ways to check (preferrably
> > > without needing login to specific Debian hosts) which pseudo-package
> > > some official area of Debian web services belong to? E.g. a public list
> > > of which team has write access to which parts of our web-facing
> > > services?
> > >
> > > I am aware of https://www.debian.org/Bugs/pseudo-packages but that's
> > > comparable to grep'ing package descriptions to pinpoint where a bug
> > > belongs, nowhere as accurate a verification as "dpkg -L ..." or
> > > "apt-file search ...".
> >
> > Karsten, Ian, and other arm people,
> >
> > This makes me wonder whether those sd card images should be packaged and
> > shipped somehow (through d-i-n-i or elsewhere), instead of just being
> > published through the installer-* directories.
> >
> > What's your take on this?
>
> Hello,
>
> personally I don't think that packaging the images would bring us
> an advantage that is worth the costs.
>
> Adding them to debian-installer-netboot-images would IMHO not
> really fit - d-i-n-i provides files for serving over the network
> ("real" netboot stuff, i.e. TFTP/PXE boot), while the SD-card
> images are the ARM equivalent of the i386/amd64 mini.iso, which
> we also don't package in d-i-n-i. Besides that, finding the
> proper package to report bugs against via "dpkg -L" or "apt-file
> search" also doesn't work with the binary packages generated by
> d-i-n-i, because their actual content - against which one would
> want to file a bug - is not built by d-i-n-i but by
> src:debian-installer. This could of course be changed by
> integrating d-i-n-i into the d-i build system and making the
> packages children of d-i, but from my personal point of view I
> don't see much need for that.
I agree that easy locating how to file bug is not a big benefit: That
can be addressed by adding contact info at the bottom of the web page
serving the images.
A real benefit of shipping SD card images as binary packages would be
ease of trusted bootstrapping:
Imagine Bob, a cautious but non-geekie person. He hires an expert to
carefully inspect his laptop to ensure that it is really truly running
only Debian, no other code is installed. He then wants to install
Debian on another host. He would then need to hire an expert yet again,
because he cannot - easily and secured by APT - get install media for
another machine, but needs to use different more technical trust paths
of manually downloading and verifying stuff from the big bad internet.
If d-i images was available as binary packages, then FreedomBox could
offer an install service for custom-configured laptop setups,
dynamically injecting preseeding file into a trusted installer image.
- Jonas
--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
[x] quote me freely [ ] ask before reusing [ ] keep private
Attachment:
signature.asc
Description: signature