El 02/10/22 a las 20:42, Michael Biebl escribió:

Am 02.10.22 um 20:14 schrieb Luca Boccassi:

On Sun, 2022-10-02 at 10:52 -0700, Russ Allbery wrote:

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.

In Bullseye we changed the name/syntax for the security repository, and
for that a mention in the release notes was enough, no? Isn't this a
very similar situation?

The main difference is, that the renaming caused an error message by apt, so you knew something needed to be fixed.

For this particular change, there will be no error. So yes, I have the same fear as Russ that this particular change might go unnoticed.

Couldn't we handle this via transitional firware* non-free packages,
that depend on bookworm non-free-firmware packages?

Cheers,

-- Santiago

-----BEGIN PGP SIGNATURE-----

iHUEABYIAB0WIQRZVjztY8b+Ty43oH1itBCJKh26HQUCYzqnFAAKCRBitBCJKh26 HRh/AQCmmk9Ns958rhKwDMBz5S4AEDwuT1JnqmeFX5OpelN+qgEA5MHnoYjqRH9i NAnUm0O/7Kqx557VXQXw75lAe8I/AwI=
=zyLk
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

3 octobre 2022 11:11 "Santiago Ruano Rincón" <santiagorr@riseup.net> a écrit:> El 02/10/22 a las 20:42, Michael Biebl escribió:>> Am 02.10.22 um 20:14 schrieb Luca Boccassi:>> On Sun, 2022-10-02 at 10:52 -0700, Russ Allbery wrote:>> In Bullseye we
changed the name/syntax for the security repository, and>> for that a mention in the release notes was enough, no? Isn't this a>> very similar situation?>> >> The main difference is, that the renaming caused an error message by apt, so>> you knew
something needed to be fixed.>> >> For this particular change, there will be no error. So yes, I have the same>> fear as Russ that this particular change might go unnoticed.> > Couldn't we handle this via transitional firware* non-free packages,>
that depend on bookworm non-free-firmware packages?That would only work if we renamed all concerned binary packages, or if apt grew a "section/packagename" syntax (which would be bizarre).

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, Oct 3, 2022 at 7:31 PM Didier 'OdyX' Raboud <odyx@debian.org> wrote:

3 octobre 2022 11:11 "Santiago Ruano Rincón" <santiagorr@riseup.net> a écrit:

El 02/10/22 a las 20:42, Michael Biebl escribió:

Am 02.10.22 um 20:14 schrieb Luca Boccassi:
On Sun, 2022-10-02 at 10:52 -0700, Russ Allbery wrote:
In Bullseye we changed the name/syntax for the security repository, and
for that a mention in the release notes was enough, no? Isn't this a
very similar situation?

The main difference is, that the renaming caused an error message by apt, so
you knew something needed to be fixed.

For this particular change, there will be no error. So yes, I have the same
fear as Russ that this particular change might go unnoticed.

Couldn't we handle this via transitional firware* non-free packages,
that depend on bookworm non-free-firmware packages?

That would only work if we renamed all concerned binary packages, or if apt grew a "section/packagename" syntax (which would be bizarre).

Can we have different versions in each section?

+ non-free/pkgA version~1
+ non-free-firmware/pkgA version~2

And let non-free/pkgA version~1 just fail during upgrade and produce a migration guide.

--
Shengjing Zhu

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

El 03/10/22 a las 11:31, Didier 'OdyX' Raboud escribió:

3 octobre 2022 11:11 "Santiago Ruano Rincón" <santiagorr@riseup.net> a écrit:

El 02/10/22 a las 20:42, Michael Biebl escribió:

Am 02.10.22 um 20:14 schrieb Luca Boccassi:
On Sun, 2022-10-02 at 10:52 -0700, Russ Allbery wrote:
In Bullseye we changed the name/syntax for the security repository, and
for that a mention in the release notes was enough, no? Isn't this a
very similar situation?

The main difference is, that the renaming caused an error message by apt, so
you knew something needed to be fixed.

For this particular change, there will be no error. So yes, I have the same
fear as Russ that this particular change might go unnoticed.

Couldn't we handle this via transitional firware* non-free packages,
that depend on bookworm non-free-firmware packages?

That would only work if we renamed all concerned binary packages,

Indeed. Something like:

bullseye:
firmware-linux-nonfree (non-free)
bookworm:
firmware-linux-nonfree (non-free) - empty, that
Depends on: firmware-linux-nonfree-bookworm (non-free-firmware) -
find a better name/suffix
trixie:
firmware-linux-nonfree-bookworm (non-free-firmware) - empty
Depends on: firmware-linux-nonfree (non-free-firmware)
trixie+1:
firmware-linux-nonfree (non-free-firmware)
and so on.

It is (also) bizarre, but this would help users make sure they include
the non-free-firmware section when required. I suppose apt would
complain if it cannot satisfy the dependency due to a missing section.

or if apt grew a "section/packagename" syntax (which would be bizarre).

Beyond being bizarre, users and other tools would have to learn that
syntax.

Cheers,

-- Santiago

-----BEGIN PGP SIGNATURE-----

iHUEABYIAB0WIQRZVjztY8b+Ty43oH1itBCJKh26HQUCYzrV/AAKCRBitBCJKh26 Hb34AP9Y3GlB1c92XXWn+3L/sKVWDsV9b8LkHRl3WTkrWk9oYgEAt56jKylev6Lv T7qcEwx/Sfcjc7prOF8mO8dmu1mwngE=
=xJvR
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, Oct 3, 2022 at 11:32 PM Santiago Ruano Rincón
<santiagorr@riseup.net> wrote:

Can we have different versions in each section?

+ non-free/pkgA version~1
+ non-free-firmware/pkgA version~2

that wouldn't comply with the current policy: https://www.debian.org/doc/debian-policy/ch-binary.html#the-package-name

I don't think it's related to name policy. It's whether dak will
remove old versions in different sections.

--
Shengjing Zhu

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

El 03/10/22 a las 19:40, Shengjing Zhu escribió:

On Mon, Oct 3, 2022 at 7:31 PM Didier 'OdyX' Raboud <odyx@debian.org> wrote:

3 octobre 2022 11:11 "Santiago Ruano Rincón" <santiagorr@riseup.net> a écrit:

El 02/10/22 a las 20:42, Michael Biebl escribió:

Am 02.10.22 um 20:14 schrieb Luca Boccassi:
On Sun, 2022-10-02 at 10:52 -0700, Russ Allbery wrote:
In Bullseye we changed the name/syntax for the security repository, and >> for that a mention in the release notes was enough, no? Isn't this a
very similar situation?

The main difference is, that the renaming caused an error message by apt, so
you knew something needed to be fixed.

For this particular change, there will be no error. So yes, I have the same
fear as Russ that this particular change might go unnoticed.

Couldn't we handle this via transitional firware* non-free packages,
that depend on bookworm non-free-firmware packages?

That would only work if we renamed all concerned binary packages, or if apt grew a "section/packagename" syntax (which would be bizarre).

Can we have different versions in each section?

+ non-free/pkgA version~1
+ non-free-firmware/pkgA version~2

that wouldn't comply with the current policy: https://www.debian.org/doc/debian-policy/ch-binary.html#the-package-name

And let non-free/pkgA version~1 just fail during upgrade and produce a migration guide.

--
Shengjing Zhu

-----BEGIN PGP SIGNATURE-----

iHUEABYIAB0WIQRZVjztY8b+Ty43oH1itBCJKh26HQUCYzsAPQAKCRBitBCJKh26 HcWxAP9E6l1wdkGZBTBKJsnJomKMo/+iMkthVu30P+ShcLM6tAEAwOlcFz04aXnS lWQ75Gm0E8+goH29vTbngvP6wsPytQk=
=FcA9
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)