Hi Steve,
thanks for the update!
Am 02.10.22 um 16:27 schrieb Steve McIntyre:
* Tweaks to add the non-free-firmware section in the apt-setup module
if desired/needed.
...
If you think I've missed anything here, please let me and Cyril know -
the best place would be the mailing list
(debian-boot@lists.debian.org).
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)?
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.
* Extra d-i code to inform users about what firmware blobs have been
loaded and the matching non-free-firmware packages. Plus information
about the hardware involved. Maybe a new d-i module / udeb for this?
Exact details here still TBD. Probably the biggest individual piece
of work here.
* Tweaks to add the non-free-firmware section in the apt-setup module
if desired/needed.
* An extra boot option (a debconf variable) to disable loading extra
firmware automatically, then exposed as an extra option through the
isolinux and GRUB menus. d-i "expert mode" can also be used to tweak
this behaviour later, except (obviously) for things like audio
firmware that *must* be loaded early if they're going to be useful
at all.
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.
On Sun, Oct 02, 2022 at 04:43:47PM +0200, Michael Biebl wrote:
Hi Steve,
thanks for the update!
Am 02.10.22 um 16:27 schrieb Steve McIntyre:
* Tweaks to add the non-free-firmware section in the apt-setup module
if desired/needed.
...
If you think I've missed anything here, please let me and Cyril know -
the best place would be the mailing list
(debian-boot@lists.debian.org).
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.
Obviously we'll need to mention this in the release notes for
bookworm. Should we maybe talk about adding an upgrade helper tool?
Shengjing Zhu <zhsj@debian.org> writes:
On Sun, Oct 2, 2022 at 10:53 PM Steve McIntyre <steve@einval.com>
wrote:
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.
Obviously we'll need to mention this in the release notes for
bookworm. Should we maybe talk about adding an upgrade helper
tool?
For upgrading, people already need to edit their source list to
change the suite name, why would it hurt to add one more manual
step to change the section name?
I think the difference is that if you don't update your sources.list
to point to the new suite, your system won't upgrade and so the
problem will be very obvious. But if you currently have non-free
configured but don't add the new firmware section, everything will
appear to work but you won't get new firmware, so the problem may go unnoticed.
On Sun, Oct 2, 2022 at 10:53 PM Steve McIntyre <steve@einval.com> wrote:
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.
Obviously we'll need to mention this in the release notes for
bookworm. Should we maybe talk about adding an upgrade helper tool?
For upgrading, people already need to edit their source list to change
the suite name, why would it hurt to add one more manual step to change
the section name?
Shengjing Zhu <zhsj@debian.org> writes:
On Sun, Oct 2, 2022 at 10:53 PM Steve McIntyre <steve@einval.com>
wrote:
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.
Obviously we'll need to mention this in the release notes for
bookworm. Should we maybe talk about adding an upgrade helper
tool?
For upgrading, people already need to edit their source list to
change
the suite name, why would it hurt to add one more manual step to
change
the section name?
I think the difference is that if you don't update your sources.list
to
point to the new suite, your system won't upgrade and so the problem
will
be very obvious. But if you currently have non-free configured but
don't
add the new firmware section, everything will appear to work but you
won't
get new firmware, so the problem may go unnoticed.
Steve McIntyre <steve@einval.com> (2022-10-02):
* Extra d-i code to inform users about what firmware blobs have been
loaded and the matching non-free-firmware packages. Plus information
about the hardware involved. Maybe a new d-i module / udeb for this?
Exact details here still TBD. Probably the biggest individual piece
of work here.
Not just blobs that were loaded, but also those which might get loaded
in the installed system (since we don't have all modules around), see >hw-detect.post-base-installer.d/50install-firmware in hw-detect (udevadm
vs. modalias stuff).
* Tweaks to add the non-free-firmware section in the apt-setup module
if desired/needed.
* An extra boot option (a debconf variable) to disable loading extra
firmware automatically, then exposed as an extra option through the
isolinux and GRUB menus. d-i "expert mode" can also be used to tweak
this behaviour later, except (obviously) for things like audio
firmware that *must* be loaded early if they're going to be useful
at all.
The option/variable looks easy enough (once we decide what to call it)…
Not sure what would be best to expose it to users: bootloader menus
already have many options (text vs. graphical, normal vs. rescue, >accessibility settings, etc.), and don't get internationalization
support anyway. On the flip side, having to go through a full expert >installation is very nice.
Maybe start by documenting the option (probably installation guide plus >release notes), and of course implementing it; then see if/how we expose
it?
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.
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.
Obviously we'll need to mention this in the release notes for
bookworm. Should we maybe talk about adding an upgrade helper tool?
The main difference is, that the renaming caused an error message by
apt, so you knew something needed to be fixed.
I heartily endorse ubuntu-release-upgrader, it has been useful in addressing uncounted upgrade issues over the years and I think something like this
would be a nice addition to Debian as well. Two caveats:
- Despite this being the sanctioned upgrade path in Ubuntu for over a
decade, every single cycle we get bug reports from users who have run
into issues because they have bypassed it and done the manual sed
/etc/apt/sources.list && apt dist-upgrade. So in Debian where this has
been the norm for /two/ decades, I would not expect this to substantially
reduce the error rate in the first release where such a mechanism is
introduced. (After all, whether telling users to use a new upgrader tool
or telling them to manually add a component to sources.list, they will
have to read the release notes to know about it!)
- There are always some users that end up with buggy systems after upgrade
despite using the supported interface because they upgrade to the devel
release, and the release-upgrader is still under development up until
release so they miss out on quirks being applied - and there is no
interface for users to replay the quirks that they missed out on. Don't
repeat the same design mistake.
In the absence of a release-upgrader, the only way I see to automate this on upgrade would be to handle it in the maintainer scripts of either base-files (which I don't think the base-files maintainer would like) or apt.
Michael Biebl <biebl@debian.org> writes:
The main difference is, that the renaming caused an error message by
apt, so you knew something needed to be fixed.
One could argue that having non-free but not non-free-firmware is sufficiently strange that it would be worth a suppressable apt warning
(that you could turn off in apt.conf). I have no idea how easy that would
be to implement, though.
On Sun, Oct 02, 2022 at 03:53:00PM +0100, Steve McIntyre 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.
Obviously we'll need to mention this in the release notes for
bookworm. Should we maybe talk about adding an upgrade helper tool?
I heartily endorse ubuntu-release-upgrader, it has been useful in addressing uncounted upgrade issues over the years and I think something like this
would be a nice addition to Debian as well. Two caveats:
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.
вс, 2 окт. 2022 г. в 22:36, Steve Langasek <vorlon@debian.org>:
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.
Obviously we'll need to mention this in the release notes for
bookworm. Should we maybe talk about adding an upgrade helper tool?
I heartily endorse ubuntu-release-upgrader, it has been useful in addressing
uncounted upgrade issues over the years and I think something like this would be a nice addition to Debian as well. Two caveats:
I'd kindly ask against additional upgrade scripts. It is too easy to
miss them, especially if one has been using Debian for ages with bare
apt-get update && apt-get dist-upgrade.
Moreover such a script will not help people that are already using testing.
For the past few decades, updating the setup was always a job of the
package scripts.
I can live with an APT hook warning me if I have non-free but not non-free-firmware, but I would prefer to even do without that.
I can't think of ever having had to add anything, only
change the release name.
On 10/2/22 22:02, Russ Allbery wrote:
Michael Biebl <biebl@debian.org> writes:
The main difference is, that the renaming caused an error message by
apt, so you knew something needed to be fixed.
One could argue that having non-free but not non-free-firmware is sufficiently strange that it would be worth a suppressable apt warning (that you could turn off in apt.conf). I have no idea how easy that would be to implement, though.
Hi!
I would very much prefer having this implemented in the base_files package. This is *the* package that follows releases, so that's IMO the best
location.
I would hate having to use an upgrade program like in Ubuntu. :/
An easy check could be:
1/ are we upgrading from base-files << 12.3 (we're currently at 12.2 in Sid) AND
2/ is there the non-free repo installed in the default sources.list
AND
3/ non-free-firmware repo isn't installed
THEN
warn user with debconf.
Checking the configuration of a non-free and non-free-firmware is kind of hard, because just reading/parsing source.list and source.list.d that could be filled with non-debian repos can be quite hard. Though we could imagine tricks, like where both repo would include a special package present only
for that test, and we just see if it is available with apt-cache policy for example (this is just an idea... not sure if there's better options).
* Check/add support for the non-free-firmware section in various
places:
+ debmirror (?)
Done in debmirror 1:2.37. I guess we need to cherry-pick this to
bullseye too? I know bullseye doesn't have non-free-firmware (which
is fine, the new debmirror doesn't object), but most people running
mirrors probably run stable rather than testing.
+ ftpsync (?)
On Sun, Oct 02, 2022 at 08:21:31PM +0100, Steve McIntyre wrote:
Plus, as Shengjing Zhu points out: we already expect people to manage
the sources.list anyway on upgrades.
People that just have 'stable' in their sources.list haven't had to
do anything. I can't think of ever having had to add anything, only
change the release name.
Not even replace "stable/updates" with "stable-security" during the upgrade from buster to bullseye ?
Plus, as Shengjing Zhu points out: we already expect people to manage
the sources.list anyway on upgrades.
Le Mon, Oct 03, 2022 at 12:33:20AM +0200, Mattia Rizzolo a écrit :
I can live with an APT hook warning me if I have non-free but not
non-free-firmware, but I would prefer to even do without that.
In addition, how about distributing the firmware in both 'non-free' and 'non-free-firmware' at the same time for a release or two ?
On Sun, Oct 02, 2022 at 03:53:00PM +0100, Steve McIntyre 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.
Obviously we'll need to mention this in the release notes for
bookworm. Should we maybe talk about adding an upgrade helper tool?
I heartily endorse ubuntu-release-upgrader, it has been useful in addressing uncounted upgrade issues over the years and I think something like this
would be a nice addition to Debian as well. Two caveats:
- Despite this being the sanctioned upgrade path in Ubuntu for over a
decade, every single cycle we get bug reports from users who have run
into issues because they have bypassed it and done the manual sed
/etc/apt/sources.list && apt dist-upgrade. So in Debian where this has
been the norm for /two/ decades, I would not expect this to substantially
reduce the error rate in the first release where such a mechanism is
introduced. (After all, whether telling users to use a new upgrader tool
or telling them to manually add a component to sources.list, they will
have to read the release notes to know about it!)
- There are always some users that end up with buggy systems after upgrade
despite using the supported interface because they upgrade to the devel
release, and the release-upgrader is still under development up until
release so they miss out on quirks being applied - and there is no
interface for users to replay the quirks that they missed out on. Don't
repeat the same design mistake.
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.
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:I think in the absence of a release upgrade script (which I very much
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.
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?
Couldn't we handle this via transitional firware* non-free packages,
that depend on bookworm non-free-firmware packages?
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:I think in the absence of a release upgrade script (which I very much
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.
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?
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: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?
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'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
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: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?
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'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"
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"
On Thu, Oct 06, 2022 at 05:13:22PM +0200, Tobias Frost wrote:
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"
Failing on installation is a terrible user experience, let's not, pretty please.
Cheers,
Julien
On Thu, Oct 06, 2022 at 05:13:22PM +0200, Tobias Frost wrote:
Maybe and idea would to do something like isa-support does for e.g sseX-supportFailing on installation is a terrible user experience, let's not, pretty >please.
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"
On Thu, Oct 13, 2022 at 05:08:57PM +0200, Julien Cristau wrote:
On Thu, Oct 06, 2022 at 05:13:22PM +0200, Tobias Frost wrote:
Maybe and idea would to do something like isa-support does for e.g sseX-supportFailing on installation is a terrible user experience, let's not, pretty >please.
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"
It's not great, no. Do you have a better suggestion for making sure
people update sources.list?
I'd prefer if we could make things work vs making things fail,
however loudly.
On Thu, 2022-10-13 at 17:35 +0200, Julien Cristau wrote:
I'd prefer if we could make things work vs making things fail,
however loudly.
There seem to be a few ways to deal with this transition:
1. Document it in the release notes and let users handle it. This means
lots of users won't get security updates for firmware (which are mostly
only issued for x86 CPU microcode), since lots of folks won't read the release notes. This also means lots of support requests when users
can't find the firmware package they wanted.
2. Add some code somewhere to automatically modify the apt sources,
somehow ensure that code is run by all Debian users and hope that other automated processes (like ansible/puppet) don't overwrite those changes
and hope that users aren't storing apt sources config in packages,
which would mean conffile prompts after the modification happens.
3. Add some code to apt to download non-free-firmware when non-free is available in the sources and the downloaded Release files. This would
solve the issue for Debian and all other derivatives too, if they
decide to add a new non-free-firmware component too. This might not
be accepted by apt developers as it is kind of a hack to special-case
Debian component semantics in apt, although maybe a component mapping
config option would be accepted. This might result in extra Debian
support requests when users notice the new component in `apt update`.
This might not work for users of tools not based on apt, like cupt?
This wouldn't result in users without non-free getting any non-free
firmware though, which maybe we want since it is the new default?
4. Keep all non-free-firmware packages in non-free too. This would be backwards compatible, but may expose bugs in dak, debian-cd, apt and
other tools, so IIRC this has been vetoed by the archive and CD teams.
This also wouldn't result in users without non-free getting any of the non-free firmware, which maybe we want since it is the new default?
Personally I would choose 4 first, I expect any potential issues could
be easily fixed before the freeze. Next I would choose 3. Next I would
choose 1 because I think /etc belongs to the sysadmin not packages.
El 14/10/22 a las 13:32, Paul Wise escribió:
On Thu, 2022-10-13 at 17:35 +0200, Julien Cristau wrote:
I'd prefer if we could make things work vs making things fail,
however loudly.
There seem to be a few ways to deal with this transition:
1. Document it in the release notes and let users handle it. This means lots of users won't get security updates for firmware (which are mostly only issued for x86 CPU microcode), since lots of folks won't read the release notes. This also means lots of support requests when users
can't find the firmware package they wanted.
2. Add some code somewhere to automatically modify the apt sources,
somehow ensure that code is run by all Debian users and hope that other automated processes (like ansible/puppet) don't overwrite those changes
and hope that users aren't storing apt sources config in packages,
which would mean conffile prompts after the modification happens.
3. Add some code to apt to download non-free-firmware when non-free is available in the sources and the downloaded Release files. This would
solve the issue for Debian and all other derivatives too, if they
decide to add a new non-free-firmware component too. This might not
be accepted by apt developers as it is kind of a hack to special-case Debian component semantics in apt, although maybe a component mapping config option would be accepted. This might result in extra Debian
support requests when users notice the new component in `apt update`.
This might not work for users of tools not based on apt, like cupt?
This wouldn't result in users without non-free getting any non-free firmware though, which maybe we want since it is the new default?
4. Keep all non-free-firmware packages in non-free too. This would be backwards compatible, but may expose bugs in dak, debian-cd, apt and
other tools, so IIRC this has been vetoed by the archive and CD teams.
This also wouldn't result in users without non-free getting any of the non-free firmware, which maybe we want since it is the new default?
Personally I would choose 4 first, I expect any potential issues could
be easily fixed before the freeze. Next I would choose 3. Next I would choose 1 because I think /etc belongs to the sysadmin not packages.
5. transitional packages along with a helper package (that fails or
success during install) to prompt the user so they add non-free-firmware section when needed.
Is there any reason why you are not considering 5.?
On Thu, 2022-10-13 at 17:35 +0200, Julien Cristau wrote:
I'd prefer if we could make things work vs making things fail,
however loudly.
There seem to be a few ways to deal with this transition:
2. Add some code somewhere to automatically modify the apt sources,
somehow ensure that code is run by all Debian users and hope that other automated processes (like ansible/puppet) don't overwrite those changes
and hope that users aren't storing apt sources config in packages,
which would mean conffile prompts after the modification happens.
4. Keep all non-free-firmware packages in non-free too. This would be backwards compatible, but may expose bugs in dak, debian-cd, apt and
other tools, so IIRC this has been vetoed by the archive and CD teams.
This also wouldn't result in users without non-free getting any of the non-free firmware, which maybe we want since it is the new default?
Personally I would choose 4 first, I expect any potential issues could
be easily fixed before the freeze.
On Thu, 2022-10-13 at 17:35 +0200, Julien Cristau wrote:
I'd prefer if we could make things work vs making things fail,
however loudly.
There seem to be a few ways to deal with this transition:
4. Keep all non-free-firmware packages in non-free too. This would be backwards compatible, but may expose bugs in dak, debian-cd, apt and
other tools, so IIRC this has been vetoed by the archive and CD teams.
This also wouldn't result in users without non-free getting any of the non-free firmware, which maybe we want since it is the new default?
3. Add some code to apt to download non-free-firmware when non-free is available in the sources and the downloaded Release files. This would
solve the issue for Debian and all other derivatives too, if they
decide to add a new non-free-firmware component too. This might not
be accepted by apt developers as it is kind of a hack to special-case
Debian component semantics in apt, although maybe a component mapping
config option would be accepted. This might result in extra Debian
support requests when users notice the new component in `apt update`.
This might not work for users of tools not based on apt, like cupt?
This wouldn't result in users without non-free getting any non-free
firmware though, which maybe we want since it is the new default?
1. Document it in the release notes and let users handle it. This means
lots of users won't get security updates for firmware (which are mostly
only issued for x86 CPU microcode), since lots of folks won't read the release notes. This also means lots of support requests when users
can't find the firmware package they wanted.
I heartily endorse ubuntu-release-upgrader, it has been useful in addressing uncounted upgrade issues over the years and I think something like this
would be a nice addition to Debian as well. Two caveats:
5. transitional packages along with a helper package (that fails or
success during install) to prompt the user so they add non-free-firmware >section when needed.
Is there any reason why you are not considering 5.?
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 360 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 128:36:48 |
| Calls: | 7,686 |
| Files: | 12,828 |
| Messages: | 5,711,092 |