El 06/10/22 a las 17:13, Tobias Frost escribió: > 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.
Good point!
> 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"
And this could solve the issue, indeed. Picking up my other mail in the
thread, the transitional packages could be summarised like this:
bullseye:
firmware-linux-nonfree (non-free)
bookworm:
firmware-linux-nonfree (non-free) - empty
Depends: firmware-linux-nonfree-bookworm* (non-free-firmware) |
non-free-firmware-needed-warning-package
trixie:
firmware-linux-nonfree-bookworm (non-free-firmware) - empty
Depends: firmware-linux-nonfree (non-free-firmware)
trixie+1 (forky):
firmware-linux-nonfree (non-free-firmware)
and so on.
* find a better name/suffix
Would this make sense?
I could volunteer to test this and propose the needed new package,
unless someone else wants to do it.
Cheers,
-- Santiago
signature.asc
Description: PGP signature
