(16:45:08) superm1: it is a kind of unfortunate experience that it done in the shell script for oem-config-firstboot right now, because after that pretty oem-config wizard gets done it drops you to a black screen with the machine spinning for a minute or two
(16:45:16) Evan: and you might not want them removed, if you set the preseed accordingly
(16:45:25) Evan: hm
(16:46:15) Evan: perhaps we could meet halfway by involving plymouth?
(16:46:24) superm1: so if it doesn't "break" it would be better if that preseed's logic was moved into the same place as all this remove extras logic
(16:46:32) superm1: yeah that would probably be sufficient too
(16:49:53) Evan: Looking at the code, I don't have a strong feeling either way.  cjwatson?
(16:51:44) cjwatson: I'm not sure I follow the question
(16:54:12) superm1: the question is moving the code to remove oem-config from oem-config-firstboot into remove_extras (pulling the feet from under oem-config/ubiquity, hopefully it all being in memory at that point) or adding some plymouth magic to not show a black screen after oem-config is done before gdm comes up while it's removed there
(16:55:01) superm1: if the former is selected, oem-config/late_command would need to be moved up too
(16:55:19) cjwatson: oh, right
(16:55:40) cjwatson: I'm dubious that it will actually work reliably; I'm OK with it if it does
(16:56:08) cjwatson: I don't like relying on things being in cache more than we have to, especially for memory-hungry things like ubiquity
(16:56:46) cjwatson: on a possibly related note, I was working on splitting out a ubiquity-common package, which might reduce the impact of having oem-config remain installed
(16:57:06) cjwatson: and would be useful to avoid a bunch of dependencies - but I haven't finished that yet
(16:57:14) superm1: it's still loading all sorts of debconf templates after that point of remove_extras, so i'm starting to think it wouldn't work properly either