Re: Firmware GR result - what happens next?
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
>
Reply to: