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

Building d-i using wheezy-backports bits



Hi folks,

as mentioned earlier this month, I had a little proof of concept for
Paris Mini-DebConf 2014[1]. I've polished a few things, so here we go.

 1. https://lists.debian.org/debian-boot/2014/01/msg00239.html

[ I've set reply-to: -boot@ for a few questions I'd like answers to /
comments on; -backports@/-cd@/-kernel@ are in cc for information. ]


Short summary
=============

The idea is to build stable images, pulling a few bits from
stable-backports, most notably the linux kernel, for improved hardware
support. I'll talk about wheezy later on, but the basics should also
work for later stable releases.

There are different topics which I believe could be discussed more or
less separately. I've emphasized the QUESTIONS in the following
sections (only in I/II, later sections should be more informational,
and hopefully not controversial).


I. How to build and run images
==============================

At least 2 source packages need updating:

 1. debian-installer, so that one can upload to wheezy-backports, and
    get extra bits set up, in order to pull the kernel and some kernel
    modules from wheezy-backports. You can find a few patches for this
    in my wheezy-backports-v3 branch:
      http://git.mraw.org/?p=debian-installer.git;a=shortlog;h=refs/heads/wheezy-backports-v3
      git://git.mraw.org/debian-installer.git

    [The top two commits are just there for testing purposes. You can
     play at home using the following command. I haven't tested other
     image types just yet:
       make USE_UDEBS_FROM=wheezy USE_BACKPORTS_FROM=wheezy-backports rebuild_netboot-gtk
    ]

    Pulling kernel module udebs from wheezy-backports is easy since
    they don't exist in wheezy, so apt happily finds and installs
    them. Pulling some targeted components like the one mentioned
    below hasn't been investigated yet. [I've been using localudebs/
    for now.]

    QUESTION: How to specify which extra bits to pull from
              wheezy-backports?

 2. net-retriever, which needs to pull regular bits from wheezy, and
    kernel module udebs from wheezy-backports. Unfortunately, contrary
    to the above, anna is used here, instead of apt. That means using
    an overlay (not self-contained) suite like wheezy-backports isn't
    possible by default. You'll find patches and rationale for them in
    my backports-v1 branch:
      http://git.mraw.org/?p=net-retriever.git;a=shortlog;h=refs/heads/backports-v1
      git://git.mraw.org/net-retriever.git

    I'm not yet convinced about “resolve conflicts with backports”
    vs. “resolve conflicts with stable”. See commit message:
      http://git.mraw.org/?p=net-retriever.git;a=commitdiff;h=d2de776325e65a667a3c4f3f6901aa2b1bd5ae5f

    QUESTION: Should we pick a different policy? If we were to pick a
              handful of packages from backports, how to do that?
              [Also, see above question.]


II. How to install a backported kernel
======================================

Here's what I did for my PoC at Mini-DebConf (warning, not nice):

 a. I added a finish-install script which would unconditionally enable
    backports and install a hardcoded kernel package using “apt-get -t
    wheezy-backports $kernel”. (Yes, this is sad; a reason for this
    was that wheezy's apt-setup is lacking the backports code entirely.)

Why did I do that? One of the first thing we install in /target is the
target kernel. At this point, apt-setup hasn't run, so hasn't had a
chance to set up extra repositories in sources.list. Even if it did,
it's using apt-install, which doesn't know about backports.

Now here's another way which doesn't look so scary:

 b. 1) Make sure the kernel installation step still installs stable's
       kernel (which might not be functional, but having it shouldn't
       hurt; and not changing such critical code doesn't look too bad…),
       and make sure it stores the package name somewhere for later use.
    2) Patch apt-setup so that wheezy-backports gets automatically
       enabled when such an installation medium is detected
       (e.g. /etc/udeb-backports-source exists).
    3) Keep a finish-install script which would use the first two
       steps to complete the installation.

QUESTION: Is there any saner/more straightforward/better option here?

QUESTION: How do we make sure we pull the relevant patched packages at
          this point? (apt-setup comes to mind, ditto for the package
          possibly containing the finish-install script.) [Also, see
          questions in the first section.]


III. How/When to upload
=======================

Probably not before we've uploaded d-i with the same kernel version
into unstable, and not before it has entered testing. That would fit
the usual backports policy.

Also, dak's configuration wants to be adjusted to support
backports-like versioning.


IV. How to maintain wheezy-backports compared to master
=======================================================

Since master both gets kernel config updates (which we want for
backports) and many other irrelevant stuff, I'm a bit undecided on how
to keep track of wheezy-backports: either cherry-pick relevant stuff
from master; or merge regularly, reverting unnecessary bits. I would
tend to go with the former.


V. How to build official images
===============================

That's a topic for debian-cd, and for another day.


VI. Thanks…
===========

… for reading so far, and even more so if you're about to hit “reply”
and send interesting feedback. ;-)


Mraw,
KiBi.

Attachment: signature.asc
Description: Digital signature


Reply to: