On Wed, 2016-09-21 at 08:31 -0500, S. wrote:
On Wed, 21 Sep 2016 09:21:34 +0200, DimStar wrote:
In this case I think it's best if you also maintain an own patch on top of control.xml; it's not that this package would be changing that often- and the patch should be rather low maintenance.
Hi Dominique, thanks for the reply.
I guess that sounds like a reasonable compromise. I don't fully understand how the live-installer works. What other things could change in Tumbleweed that would break compatibility with the live installer?
Thanks again.
Difficult to say - one of the biggest issues of the net installer, amongst the various ways it could break booting was that it basically just 'dumps' the live image on your HDD and 'hacks up a few configurations' - far from optimal or from the controlled / tested setups a usual install has. And there lies also the advantage of using the net installer in the live session now: it does a regular installation and does not dump the current disk image on the hdd... of course, in many cases it worked sufficiently good - yet, there were often enough subtle differences in the installed system that can be a pain to dig out (services needed be disabled on the live, so they ended up disabled on the installed system too, even though normal install would enable them and such things). AS for how many ways I can think of the installer breaking: probably too many. Most of them are unlikely to be very realistic though. AS the biggest risk I'd likely list some arch changes inside yast or ruby upgrades that might hit Tumbleweed; the live installer won't be tested / fixed (of course somebody can step up and fix it - but the YaST team likely won't do it - and it won't be a criteria to not change the ruby version) Cheers, Dominique