09.11.2016 19:43, intrigeri wrote: > Michael Tokarev: [] >> On all my servers where qemu is used, upgrading to this new >> version pulls in a TON of new dependencies, >> […] >> Once we enable that, all server people will start screaming >> out very very loud. > > Thanks for these details! Now, I'd like to understand better why > exactly this is a problem serious enough that 1. it will make people > scream very very loud; 2. it needs to be solved by other people than > those who care that much about the list of packages installed on their > virtualization hosts. > > The dependencies you list are mostly libraries, that are harmless even > in a server context, so I assume that the biggest problem is disk > space, right?
Well. It's a lot of libs, most of them are complex, and with various security issues. During jessie lifetime, I've seen more security fixes in "headful" part of packages (on my desktop system) than on a headless server install. Pushing all these client libs to server means many more security fixes which needs to be reviewed. Most of these will be just unused baggage which just needs constant attention. The prob isn't the disk space, no, disks are cheap these days. But the maintenance on the end-user part. I dunno. Maybe I'm too old-fasioned, and used to nice and clean systems. We had numerous requests to create qemu-system-headless package(s), and numerous complains that virtualization brings up lots of unnecessary dependencies. We've a bug report about this open, too. And we already had that - when I switched to gtk2 (at the time), several people wrote to me asking about the new baggage (in UNSTABLE!) for servers with gtk2 (I had to revert back to sdl1 because gtk support wasn't ready, or else I'd had to deal with that baggage requests). I dunno. For me myself I'd not add the extra stuff for our servers if it's possible to avoid that. But that's just me. I understand other people have different uses. If it all were easily separatable, that'd be great... I already sort-of-modularized gtk. Now virtio-gpu needs to be modularized too (or else virglrenderer brings most of that baggage back), but how many packages we'll have to create? As stated in other email, virglrendered can be used with spice too, so it can't be part of qemu-system-display-gtk (say) package, it needs to be in separate package which is recommended by q-s-display-gtk and q-s-display-spice (say) packages... Oh well.. Any other thoughts? :) Thanks, /mjt
