On Thu, Oct 06, 2022 at 05:03:20PM +0200, Julien Cristau wrote: > On Thu, Oct 6, 2022 at 15:45:25 +0100, Steve McIntyre wrote: > > > On Wed, Oct 05, 2022 at 10:11:27PM +0200, Julien Cristau wrote: > > >On Sun, Oct 02, 2022 at 08:21:31PM +0100, Steve McIntyre wrote: > > >> On Sun, Oct 02, 2022 at 11:08:47AM -0400, Michael Stone wrote: > > >> >On Sun, Oct 02, 2022 at 03:53:00PM +0100, Steve McIntyre wrote: > > >> >> On Sun, Oct 02, 2022 at 04:43:47PM +0200, Michael Biebl wrote: > > >> >> > What's the plan for upgraded systems with an existing > > >> >> > /etc/apt/sources.list. > > >> >> > Will the new n-f-f section added on upgrades automatically(if > > >> >> > non-free was > > >> >> > enabled before)? > > >> >> > > >> >> So this is the one bit that I don't think we currently have a good > > >> >> answer for. We've never had a specific script to run on upgrades (like > > >> >> Ubuntu do), so this kind of potentially breaking change doesn't really > > >> >> have an obvious place to be fixed. > > >> > > > >> >Is there a reason to not continue to make the packages available in > > >> >non-free? > > >> >I don't see a reason to force any change on existing systems. > > >> > > >> Two things: > > >> > > >> 1. I'm worried what bugs we might expose by having packages be in two > > >> components at once. > > >> 2. I really don't like the idea of leaving two different > > >> configurations in the wild; it'll confuse people and is more > > >> likely to cause issues in the future IMHO. > > >> > > >> Plus, as Shengjing Zhu points out: we already expect people to manage > > >> the sources.list anyway on upgrades. > > >> > > >I think in the absence of a release upgrade script (which I very much > > >doubt will happen, and be tested, and we can rely will be used, for > > >bookworm), Michael's suggestion seems like a reasonable way forward. I > > >imagine we'll need to patch dak to allow that, but it seems like it > > >should be tractable? > > > > I'm also worried what effect this will have on other tools that have > > to grok the archive (mirror tools, debian-cd, etc.). I'm not going to > > try and veto having things in more than one component, but (ugh!) I > > really think it's ugly. Actually, I think I'd much prefer Santiago's > > idea: > > > > > Couldn't we handle this via transitional firware* non-free packages, > > > that depend on bookworm non-free-firmware packages? > > > > We'd need to add some transitional binary packages for the small > > number of n-f-f source packages. That way people would get errors from > > apt if they don't read our warnings and update. Maybe this is a way > > forward? > > > I don't think that will work well, the packages will likely just be held > at the old version if the new ones are uninstallable because the new > component isn't enabled.
Maybe and idea would to do something like isa-support does for e.g sseX-support on CPUs that does not have that feature: It fails on installation with an debconf message, IIRC. So that would allow something like "new package" | "you-need-to-enable-nonfree-firmware-reminder-package" > Cheers, > Julien >