On Fri, Nov 17, 2017 at 5:56 AM, Michael Tokarev <[email protected]> wrote:
> 09.11.2017 16:47, Christian Ehrhardt wrote:
>> Package: qemu
>> Version: 1:2.10.0+dfsg-2
>> Severity: important
>>
>> TL;DR:
>> - rom size change (coming on next ipxe merge for Debian) break migrations
>> - we need a way to allow incoming migrations to work but still be able
>> to update roms
>> - I suggest a machine type based mapping to compat roms
>
> I'm strongly against these changes in debian infrastructure.
> Upstream will face the same problem once they import new ipxe,
> and will have to deal with this somehow as well. If we will
> follow this change, we will both stay compatible with upstream
> and ourselves. But adding this incompatibility to debian/ubuntu
> and dealing with it inside debian/ubuntu makes us incompatible
> with both upstream (and the world) and partially ourselves..
>
> Especially if upstream choses to do it the other way, we'll
> either have to support our solution (TOGETHER with upstream
> solution) for some singnificant amount of time, or we'll become
> incompatible with ourselves again.
I see and agree with your point - IF - upstream would go along with
the same versions and handles it.
Looking back there are a few issues that make me doubt we can just
"rely on upstream" in this case:
1. ipxe and qemu are different projects nothing forces them to e.g.
match qemu 2.11 with a given ipxe version.
The ones who define what goes together are the Distributions => we
That is why I doubt there will be an upstream "fix".
2. rom sizes are build option dependent, thereby each
distribution/upstream will face the issue at a different point in
time.
I was able to prove that e.g. with the debian build options it
will pass that size already as of today, but there is nothing in qemu
yet.
Due to (1)+(2) upstream qemu can't decide to which version to couple
such changes - they just can't know for all downstreams as they are
different.
3. Deadlines are different Buster vs Ubuntu 18.04 vs
other-Distro-releases we all will have to make the final "cutoff" at a
different time.
That further limits the chance that upstream will fix it for all of us.
4. I got the impression this is nothing Upstream usually handles. Look
at the (not) overwhelming feedback to [1] and even those I got were:
a) we solved that long ago via padding, you are doomed now
b) we fixed it with a workaround ourself
Yes, I clearly see the maintenance pain this might bring - and I'd be
very happy if I could assume we could "just go with upstream on this".
But I doubt it will happen, so I wanted to make sure we have a way to
"get out of it" on our own.
Once the new ipxe is uploaded it is kind of "too late", size will
change and you'll see all the issues I outlined - that is why I was
calling for coordination up front.
With that in mind what should we do now?
- Wait until qemu 2.11 is out and see if there is anything happening
upstream (I didn't see any related action so far)?
- If there is no change upstream eventually, then consider my
suggestion (or any others if there are some)?
- Go back to upstream on my thread with these issues - especially your
POV that you'd expect upstream to handle it?
[1]: http://lists.nongnu.org/archive/html/qemu-devel/2017-11/msg00193.html
