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
