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.
Cheers, Julien
