Re: Building d-i using wheezy-backports bits
Hi Cyril,
Le jeudi, 30 janvier 2014, 02.51:48 Cyril Brulebois a écrit :
> 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
Thanks for the report; your progress on that front is really awesome!
> 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:
> (…
> QUESTION: How to specify which extra bits to pull from
> wheezy-backports?
The most logical place to store this information would be in build/pkg-
lists/, with either version specifiers ( lowmemcheck=1.40~bpo70+1 ) or
target release specifiers ( lowmemcheck/wheezy-backports ). That's for
storing the information; but that involves patching various tools. The
first I've encountered was get-packages (patch attached).
As far as I could test, the attached patch is sufficient to allow either
of the syntaxes in build/pkg-lists/ to build netboot-gtk on amd64.
(Now that's probably unrelated, but mini.iso fails on me with "Kernel
panic - not syncing: No init found.")
> 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.
> (…)
> I'm not yet convinced about “resolve conflicts with backports”
> vs. “resolve conflicts with stable”.
> (…)
> 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.]
(Easier said than done, but) I would tend to think that making anna
understand both of the above syntaxes would empower it most. Now, that's
certainly quite a bunch of work and I think your approach of merging the
Packages* files is good for now. As for conflicts resolution, I agree
with your current "resolve conflicts with backports", given that most
udebs are uploaded by -boot (meaning that udebs in backports are there
for a reason).
The next step (as you wrote) would be to allow suite or version
specifications to be consumed by the Packages* files merger, which is
still quite easier than patching anna's resolver I guess.
> II. How to install a backported kernel
> ======================================
> (…)
> Now here's another way which doesn't look so scary:
>
> 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.
Sure. Having the stable kernel installed in all cases is definitely
good.
> 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).
That would be patching /usr/lib/apt-setup/generators/93backports to
ignore apt-setup/services if the flagfile exists; patch attached.
> 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.)
Hrm. base-installer/library.sh 's pick_kernel makes sure that one gets
the "currently running" kernel image installed. It might be easier to
let that happen and _then_ make sure stable's kernel is installed… Note
that it uses `apt-cache search "^linux-image"` in the target to find the
needed packages…
I'm not navigating very easily through these installation steps, so I'll
let someone else chime with better ideas here…
> 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.
It looks like a matter of intent: either we want "stable d-i + kernel
from backports + glue" or "testing d-i built against stable + kernel
from backports". The first is less risky for what d-i is concerned,
while the latter allows a wider testing of the jessie d-i… The latter is
what you have in your branch currently, no?
As for maintaining the branches, I'd rather go for cherry-picking what's
relevant on a branch based on the latest stable d-i (aka we agree I
think).
> VI. Thanks for reading so far, and even more so if you're about to hit
> “reply” and send interesting feedback. ;-)
I hope it was.
Cheers,
OdyX
P.S. It took me time to realize the git URL for your repositories were
in your mail, and not on the gitweb interface. Making these appear on
the gitweb is a matter of defining
@git_base-url_list = ("git://git.mraw.org");
in /etc/gitweb.conf.>From 12498a5fa15f1ce09c0e1751461902255e474d7a Mon Sep 17 00:00:00 2001
From: Didier Raboud <odyx@debian.org>
Date: Thu, 30 Jan 2014 13:58:47 +0100
Subject: [PATCH] In get-packages, strip /suite or =version specifiers in
package names
---
build/util/get-packages | 2 ++
1 file changed, 2 insertions(+)
diff --git a/build/util/get-packages b/build/util/get-packages
index 7a987ae..d2314f4 100755
--- a/build/util/get-packages
+++ b/build/util/get-packages
@@ -204,6 +204,8 @@ lnpkg() {
}
for package in $PACKAGES; do
+ # Strip eventual /suite or =version specifiers for packages
+ package=$(echo $package | sed -e 's#[/=].*$##g')
lnpkg $package $APTDIR/cache/archives $UDEBDIR
lnpkg $package $DEBUGUDEBDIR $UDEBDIR
if [ ! -e $UDEBDIR/$package.$TYPE ]; then
--
1.7.10.4
>From ac04bb30f42ae28253f12a4da2ee9f33259bb2e8 Mon Sep 17 00:00:00 2001
From: Didier Raboud <odyx@debian.org>
Date: Thu, 30 Jan 2014 15:02:38 +0100
Subject: [PATCH] If /etc/udeb-backports-source exists, ignore
apt-setup/services-select backports' option
---
generators/93backports | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/generators/93backports b/generators/93backports
index f169025..4933ceb 100755
--- a/generators/93backports
+++ b/generators/93backports
@@ -6,7 +6,7 @@ set -e
file="$1"
db_get apt-setup/services-select
-if ! echo "$RET" | grep -q backports; then
+if ! echo "$RET" | grep -q backports && ! [ -f /etc/udeb-backports-source ]; then
exit
fi
--
1.7.10.4
Reply to: