Hi all,

I'd like to give a gentle poke to this list about https://salsa.debian.org/installer-team/apt-setup/-/merge_requests/17

For some context, it's used by the Scibian derivative, which has its own
APT repositories, some of which require extra options in the
sources.list lines. For now we work with a patched apt-setup, but it
would be cleaner for us if the patch was merged "upstream". Is there a
chance that this patch could be reviewed and merged before trixie? The discussion seems to have settled down to whether to allow specifying an arbitrary option string but be restricted to the sources.list format
(current approach) or to implement a debconf option for every possible
apt source option, and implement that both for sources.list and deb822
formats.

Please advise :-)

Roland.

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

Um… ping ?

Le 24/02/2025 à 09:50, Roland Mas a écrit :

Hi all,

I'd like to give a gentle poke to this list about https://salsa.debian.org/installer-team/apt-setup/-/merge_requests/17

For some context, it's used by the Scibian derivative, which has its
own APT repositories, some of which require extra options in the
sources.list lines. For now we work with a patched apt-setup, but it
would be cleaner for us if the patch was merged "upstream". Is there a
chance that this patch could be reviewed and merged before trixie? The discussion seems to have settled down to whether to allow specifying
an arbitrary option string but be restricted to the sources.list
format (current approach) or to implement a debconf option for every
possible apt source option, and implement that both for sources.list
and deb822 formats.

Please advise :-)

Roland.

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

Hi Roland,

Sorry for the delay, for the very long answer, and for the snowball
that's about to start rolling. I'm not cc-ing either #1032131 (which has
lots of answer already, a bunch of them about a temporary, different
problem with apt) or #1093762 at this point, but I'm aware of both.

Roland Clobus and Philip Hands, I'm explicitly cc-ing you because I'm
only realizing now how everything is centered around sources.list at the moment, and how generators/60local and the way generators are called is
going to limit freedom of movement here.


Roland Mas <[email protected]> (2025-02-24):

I'd like to give a gentle poke to this list about https://salsa.debian.org/installer-team/apt-setup/-/merge_requests/17

In general, it's always a good idea to involve the list, I'm not sure
anyone monitors all merge requests.

For some context, it's used by the Scibian derivative, which has its
own APT repositories, some of which require extra options in the
sources.list lines. For now we work with a patched apt-setup, but
it would be cleaner for us if the patch was merged "upstream". Is
there a chance that this patch could be reviewed and merged before
trixie?

This still looks doable *in theory*. Feel free to add it to <https://wiki.debian.org/DebianInstaller/Trixie/Wishlist>.

The rest of my answer might look like a rollercoaster regarding your
particular request, but I hope in the end you'll see that I'm trying to
find a positive answer in all cases. That's at least my intent.

The discussion seems to have settled down to whether to allow
specifying an arbitrary option string but be restricted to the
sources.list format (current approach) or to implement a debconf
option for every possible apt source option, and implement that both
for sources.list and deb822 formats.

Until “recent” apt versions start prodding users about the sources modernization, and having spotted no patches to support deb822 format
it looked to me like we might get away with sticking to sources.list.

I have seen it pop up in recent installation reports, I know people
have asked for it for a while, but I cannot find a patch/MR to review or
extend at the moment. If that were available (which until an hour or two
ago I thought was the case), I was meaning to look into it, test it up,
and fix whatever needs fixing (the extended firmware support introduced
in bookworm meant tweaking sources.list after the fact, based on my
vague recollection — not double checked yet).


My current plan is to start releasing D-I Trixie RC 1 with sources.list
support as soon as other components are ready, and delay anything deb822-related until RC 2.


(Rollercoaster warning: ride up)

Would it make sense to you to have (in 13.0) the main repositories
configured as debian.sources and the local repositories configured as local.list or some such? This would make it easier on users (no prodding
from apt right after installation, unless they also configure local
repos)), while making your MR *mostly* work as is, without having to add per-option support. If apt would allow noninteractive use and would be trustworthy, we could even write that local.list file and run `apt modernize-sources` afterwards to do the conversion.

(Rollercoaster warning: ride down)

The problem is that apt-setup is currently working on a single
sources.list file, and having the 60local generator work on a different
one would likely mean reworking the debconf automaton quick a bunch. It
could also break the CI (mostly run/monitored by the other Roland and by
Phil, hence the explicit cc).

Thinking about this a little more, this probably means that switching to debian.sources would require very special care to avoid breaking generic “local support” (i.e. the current state, without your MR). In the end,
it might be safer to stick to generating the traditional sources.list
until someone comes up with a rock-solid patch series that would:
- obviously write the usual lines for the main/security/etc. repos;
- not break firmware support (that part I can check/fix);
- not break local support, either by having local.list alongside the
debian.sources, or by having local.sources, which is critical for
the CI at the very least.

I am not convinced this is achievable before trixie. But again, maybe
I've missed some patches, MRs, or volunteers! That's entirely possible.

(Rollercoaster warning: back to start, about to ride up again)

In that case, I'm not sure how your MR would fit in the picture. *If* we
went ahead and overhauled apt-setup for deb822 support, that could lead
to two situations:
- local support is kept as traditional .list, in which case your MR
should be easy-ish to adjust (I'd hope);
- local support is rewritten with new .sources, in which case your MR
is probably becoming moot and would need the other approach you
mentioned (multiple to many debconf options); alternatively, I'd be
fine to have a less generic approach where you'd implement support
only for the option(s) you care about and need.

In both cases, I would hate for you (or anyone else) to be working in a
hurry to either adapt the existing merge request (.list) or rewrite it
to support one or multiple or all options (.sources). Instead, I would recommend getting that done at the beginning of the forky release cycle,
and I would advocate for that to be considered for inclusion in a point release. (Either accepting it outright or discussing it with other
release team members if some doubts arose.)

Of course, if we were to stick to .list entirely, your MR is likely to
get in as is (I didn't *really* review it just yet), but I wanted to get
the harder options out of the way first…


To conclude, crazy idea: what if we did nothing in a rush on the d-i
side right now, and only attempted `apt modernize-sources` after writing
the traditional sources.list? This would be assuming that:
- It can run noninteractively and can be trusted to handle all the
flexibility generators/60local provides.
- Its behaviour regarding error reporting is sane enough that we can do
something like “please modernize, but if that fails, remove any
possibly generated files, and let's keep the sources.list instead”.
(I'm mentioning this because at least in the past, things like
`apt-get update` could exit with some error codes that might be
surprising, depending on the kind of network errors, on the contents
of /var/lib/apt/lists, etc. I'm not complaining, just making a mental
note that sometimes success isn't binary.)

This would still leave a slight discrepancy since debootstrap currently
writes a sources.list (#1093762), but that part seems easier to tackle,
without having to rewrite the core logic of apt-setup. That would look
doable (if we wanted to do that) during the freeze, or at the beginning
of the release cycle and backported through a point release. I'm not
saying the stable release team would be happy to let that kind of
changes through, but I think we've seen bigger changes in stable over
the last few years.


End of the monologue!


Cheers,
--
Cyril Brulebois ([email protected]) <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

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

iQIzBAABCgAdFiEEtg6/KYRFPHDXTPR4/5FK8MKzVSAFAmgk2w0ACgkQ/5FK8MKz VSBQBBAAgRVb5gRUvvDG1/moJNxBnSdO7U7qcnkAWVARE2gjMoyXeCdJ1Vk5zSB2 l70np6Cr4adLjn8hrXJFWK51BsTWZvEeGn3VaZrH8TRIwKxTvm/DtS33EYWO+SgA G+zQ7+qLsa40CvHhGoHPt7UA+UvzGVoUNLYPQ11MNWODQjnB3m+0sBGb0xIUB+S3 c1Y1K4IpTtOSWWTqMIvDJUBDvu6XUN+tb1nSUD/Q+8FePkUK76xEnZR5IyIZIaFw TgvPwuraCBtajKjrAsT9wfwPzT2or71+7GswfTBgwKkBGrEgUFmg+XmEvW01exe0 t+DpeZdPv183LVEkRj10A0pG3RmTGctjRoBIfxJO57NAuKOhTJM4JYMFxvgAa1W8 R3lHiSqfa0qCeOxZhWCXL/GWGr7cYNaVfOIn9DVuZ2BPtKpKLbDnXudmnc3l3FRK Pzp35dDosVKm9EE07l/FDhqLb/7k5YTwiDEU6QrywTNeEyjgYVgmqBMzJtwyxoWy PYAE63qAf3dkMxtD7sfur81uCOwY49aj8D8IDAKnPicgGV9ChNwkMpiv8JtNk/tq SKMsfKBrWQzMakBdpCygzq7CcPwvqZLRD19btPAuqYqDcC9WW84S2y3IC+Vs2Fsh gIIn0FiLuwB8u0W79C/nkFhTb15vDdfLDp07s3wJX77v4Vpw/QM=
=1GbN
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
*

Hi,

[ cc += apt people ]

If you feel like you want the very long version of the context, feel
free to check:
https://lists.debian.org/debian-boot/2025/05/msg00201.html

Long story short: of course it'd be better to directly write deb822 data
from some template but we would need to overhaul apt-setup entirely,
which doesn't seem realistic to me at this point of the release cycle.

Cyril Brulebois <[email protected]> (2025-05-14):

To conclude, crazy idea: what if we did nothing in a rush on the d-i
side right now, and only attempted `apt modernize-sources` after writing
the traditional sources.list? This would be assuming that:
- It can run noninteractively and can be trusted to handle all the
flexibility generators/60local provides.
- Its behaviour regarding error reporting is sane enough that we can do
something like “please modernize, but if that fails, remove any
possibly generated files, and let's keep the sources.list instead”.
(I'm mentioning this because at least in the past, things like
`apt-get update` could exit with some error codes that might be
surprising, depending on the kind of network errors, on the contents
of /var/lib/apt/lists, etc. I'm not complaining, just making a mental
note that sometimes success isn't binary.)

This would still leave a slight discrepancy since debootstrap currently writes a sources.list (#1093762), but that part seems easier to tackle, without having to rewrite the core logic of apt-setup. That would look
doable (if we wanted to do that) during the freeze, or at the beginning
of the release cycle and backported through a point release. I'm not
saying the stable release team would be happy to let that kind of
changes through, but I think we've seen bigger changes in stable over
the last few years.

I haven't found a way to have some `apt modernize-sources` help message,
and it doesn't seem to be documented in apt(8), but seeing how there's a
prompt which defaults to actually modernizing (the other option is a dry
run), I've tried a simple `echo | apt modernize-sources` after a GNOME
install (laptop, French settings, Wi-Fi, GNOME, from a locally-built
netinst amd64), without any local repositories.

It did the following:
- rename sources.list into sources.list.bak
- create sources.list.d/debian.sources with one such line before each
stanza (1 for trixie [main repo], 1 for trixie-security [security
repo], 1 for trixie-updates [main repo]):
# Modernized from /etc/apt/sources.list

Of course, it's not ideal because we're:
- post-processing the old format instead of generating the new one from
the get-go (see long version for reasons not to rewrite apt-setup
right now);
- getting several “main repo” stanzas, one for trixie, one for
trixie-updates; there could be more with backports and p-u…
- leaving modernization-related comments behind, which some users might
find awkward on a freshly-deployed system;
- losing all comments (e.g. the cdrom: entry that's getting disabled,
at the top, and the relevant explanations — a full paragraph —, at
the bottom, also explanations regarding what trixie-updates is).

Counter-points, respectively:
- [I've got nothing.]
- If people care about deb822, maybe they'll find the starting point
better than historical sources.list format; also, maybe `apt
modernize-sources` could spot and merge, but that could be tricky
depending on options, etc.
- We could scratch those (but that might need some sed pattern
maintenance to keep apt and d-i aligned).
- We still have sources.list.bak behind with everything, but one would
have to know where to look. Other users might legitimately wonder
what's a .bak doing there after a fresh install, if we decided to
keep it…

Regarding basic error management, I went back to sources.list and no debian.sources, added that line at the bottom:

deb something you don't understand

and ran `echo | apt modernize-sources`; it did everything right (i.e.
scoring all points regarding what we could expect if we wanted to try
using it noninteractively from d-i):
- did not generate a partial debian.sources;
- kept sources.list;
- mentioned the first line it didn't understand (line 20); we probably
wouldn't want to echo that back to users in d-i, but that'd help
debugging (when users share their syslog or we point them to it),
e.g. in case local support (with or without Rolang Mas's feature)
confuses apt; I didn't try creating multiple problems.
- errored out with a non-0 exit code (100); again, we probably wouldn't
want to echo that back to users in d-i, but that'd help debugging by
letting us insert an explicit log message from a d-i perspective,
in addition to apt's own logs.


In other words, it looks like we would have a noninteractive way to atomatically replace sources.list with debian.sources (if everything is supported and easy), albeit not being the best representation (lack of merging)… or keep sources.list if something makes apt error out,
allowing us to log that specifically.


Maybe not too crazy an idea after all?

I'll let others comment now. Maybe CI people might want to add
`echo | apt modernize-sources` to the stack of local tweaks they have
(e.g. creating some post-install hook when preparing the image to test),
to get a better feel of that idea's viability? I'm also fine with
comments along the lines of “this is worse than sticking to historical sources.list!”.


(Curious people may want to check the current apt implementation in apt-private/private-sources.cc, ModernizeSources() and Modernize(). The
former doesn't seem to take any options (prompting then looking at a configuration option if the prompt is negative), the latter knows how to iterate over several files. I haven't tested the atomicity mentioned
above in case one file is correct and another one isn't, since apt-setup
writes a single sources.list anyway.)


Cheers,
--
Cyril Brulebois ([email protected]) <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

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

iQIzBAABCgAdFiEEtg6/KYRFPHDXTPR4/5FK8MKzVSAFAmglOJwACgkQ/5FK8MKz VSCuEQ/7BZw/fIObw5INwLKwTvqhm8t4wLfA+5l/QyRsiq9GzkjRdYe0RDdCxnZj HhotUZIZkIT5VHDJkZEX0FQrSsHMxoERbfJBaXJfM6W6BT35d2X3OW4OEmASheky q1KnJHz+JfaR9WRTkYMWB1B7o9ujFdjUzMpzsQn82CTOsO2Aqth27W57PY5m3zau xNhkArX8jIq2fFN16lNve8AcdTeJTi7w5SWIt/+efX+8M15ELPhGLfU7MzuFgrQ0 E5nd5OQ4TpYFTsLpvj7DhJs05e/DE3OI63hRr9SSZStzZb0W7XbDbzenu6C+y1A3 nMZYODiWEx4qN4Bljl9rkNd/e9226Ezv2xoc9iMGQGNhr0KG1RUAOC2LQSqbbOKd EybiAP0Gv4nf5f1Eg2ZYKRDYEOXi8jdokKRrWwknucvU+Sx9MwgghYDalPz0IiNA +EGOkGuIZ4JWgAnTUsQJNrM6MKsUfcLh7W6Ah4is5DOuPI0DToGHAd2u5l4H1lc6 +KP3MMO0OZyn9MpLnqJXWG+h1cyGkv1uf90X5I2SpErhEKtwyIKbzGafMauFL0b3 sLjGw/yn77HJoOiCt/YWRR79WPq9Pg9OQ4kCsKDYCrVEbKzx47Qx1TIdSIDqnN20 AAvc4nsXZ/D+sM4BdpFyUTxOdJnhgwegdRpi2IJMjL6EUxPhycw=
=T9ID
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
*

Cyril Brulebois <[email protected]> writes:

The problem is that apt-setup is currently working on a single
sources.list file, and having the 60local generator work on a different
one would likely mean reworking the debconf automaton quick a bunch. It
could also break the CI (mostly run/monitored by the other Roland and by Phil, hence the explicit cc).

It seems to me that we need a new debconf setting, so that code to
migrate towards deb822 usage can be added without immediately breaking
things.

We could have e.g. `apt-setup/use-deb822-format` that might take values
like:

`no`:
everything should be in sources.list format.

Is that what we currently have, or are we already in a mixed state,
with some things generating deb822 already?
If so, perhaps this setting should just mean that other scripts can
assume that apt-setup will have produced sources.list.

'update':
use apt-get update to convert .list files

'yes-maybe':
things that know how to produce deb822 should do so,
and we get to see what breaks.

'yes':
everything should be deb822, and things producing .list style are an error

I'm thinking that most things could check for "yes*" and if that's
found, use the new deb822 code, otherwise stick with the old. There
might be a reason for also have `yes-update` as an option (do deb822 if
you can, and also run apt-get update).

I guess that things that might want to fiddle with sources.list, but can
do deb822 too, should check for sources.list.d/debian.list (or whatever apt-setup will be creating) and behave accordingly.

That way we could get on with writing new code for dealing with deb822
format, made conditional on that setting, and do some testing. Depending
on how well that goes, might decide to set it to something other than
`no` for trixie's initial release, or a point release.

Anyway, if we have some idea of the direction of travel, I'm happy to
work on the 60local stuff, and making it viable in a deb822 world.

We can also add tests on openqa for what format actually ended up on the installed systems, to see how we're progressing.

Cheers, Phil.
--
Philip Hands -- https://hands.com/~phil

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

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

iQIzBAEBCgAdFiEE3/FBWs4yJ/zyBwfW0EujoAEl1cAFAmglnCoACgkQ0EujoAEl 1cCQwg//cMrKNjZbyGI1WKKibHltNrUDHgRIfzuFpJvubKrfl9XTJDewd95Dmalm cckb/bLClcnQU/KbgpykilIdvy8eXDPKhTyiGKoPKsdCo1RKhdWM8q419sJWa6wa jh9xzCqqyQOAAJVVactbUMZoE05BdeVMI1e3ydUI2iQfkJMfgk/076Cm1cJe0HTB vNyRjiLGo98Q+bjW2G/DfofnLuhE6YurjH+rLZ0WMtfwbRjQRMltx8+L7KTwiiQn LCvAvY74+VtuQMhtFvw0tPygIxW376DyFSrtW29icCMJaQwjB4YHt41UoDj3+6HR q3Ub/0R/vIl7ckBKgxXAHbp+uR4YPYP5SkoCXJtU2E55mcm0g3Z8gV3BH8jRmsny FvF3qWBrBeKT7L5qXO+OClbgczvdOcI8UHG09VoKNfUtXvuCwKOR+FjWggoioaun AYYaPrRE88R49B9T+iSqdI48WATKgAvy05XX8mlHVul5FR4ZWY+di0zMihO6r6p8 YGjvkQVO2nxbT7kmcNGaTUh/qg8BajMbcIRndC309ZQ3Hf84koxiUCRCUd1zCCbn Uzb+szMFZE5HKSum/PwGtc8dtk1E/MB1r/pwwZdowewnOfqBaUEmY99HOHmlUxUZ i0MWh+aBl/Kr+eJZXvLYRMghDHoHQrhEVN/jRdETOJ/SIItL5x4=7o/a
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gatewa

Philip Hands <[email protected]> (2025-05-15):

Cyril Brulebois <[email protected]> writes:

The problem is that apt-setup is currently working on a single
sources.list file, and having the 60local generator work on a different
one would likely mean reworking the debconf automaton quick a bunch. It could also break the CI (mostly run/monitored by the other Roland and by Phil, hence the explicit cc).

It seems to me that we need a new debconf setting, so that code to
migrate towards deb822 usage can be added without immediately breaking things.

We could have e.g. `apt-setup/use-deb822-format` that might take values
like:

`no`:
everything should be in sources.list format.

Is that what we currently have, or are we already in a mixed state,
with some things generating deb822 already?

[ and yes-maybe, and yes ]

What I was trying to convey above is that absolutely everything is sources.list-centric, not just the format, but also that one particular
file.

The core of the debconf state machine (what I called automaton) is about writing a temporary file, passing it to apt-setup-verify after the
generator has worked, and fiddling with $ROOT/etc/apt/sources.list.new depending on the verification; at the end of the loop, it's renaming $ROOT/etc/apt/sources.list.new into the final $ROOT/etc/apt/sources.list
if everything went OK:
https://sources.debian.org/src/apt-setup/1%3A0.194/apt-setup/#L50-L92

I'm worried about the way the current logic is written (basically
“looping over a temporary sources.list”) and about having to change it, more than about how we could pick and choose which format is generated
for which generator.

If we were to say pass an extra argument (requesting .list or .sources)
to each generator, we would need to also adjust how each generated file
is validated.

Otherwise, sure, having some setting to control which format to generate
would make it easy to test, then switch once we're confident enough. It
just looks to me that's something we can only implement after rewriting
both apt-setup and apt-setup-verify quite a bit…

'update':
use apt-get update to convert .list files

Assuming we're talking about `apt modernize-sources` here, that's the
only part that would seem easy to experiment with: we would only need
to control whether to post-process the generated sources.list file,
without starting with a big logic rewrite.


Cheers,
--
Cyril Brulebois ([email protected]) <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

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

iQIzBAABCgAdFiEEtg6/KYRFPHDXTPR4/5FK8MKzVSAFAmglvVYACgkQ/5FK8MKz VSDc/RAAvkx7g0fXOn6MZkpNoE0mNEiLpoE5sZU3sIw4mkU0f0ejEBbAPvonAHhe oOOpt+D73SGmOlXJl2SeYZHbtHVmrMRaovWr54O1OoYl6k3GzeNig1GKpjgRXQA6 pJ8482GAoZ41sFtgeO47Z+P7+whMlOpnaW1dWDTvgxZxjeqZml+8OTKQcZ1tLmKD uq59+MtnZljAeT+icXXvr5NjWyRo67Mbr8xXSEWeFl0zLSD15RiziM4N6S5L03XP BVViq6s/nyKlEEoSyfaSoPh4Fss/rGYlbRaIV+m0OB+7Wnk9LfZ0UiLBESNyTQiN 6ziXI7rOO2oXNpqj6IajHWV6pAvDi/o94I0L6OPNOS0sfq1M50joADUshBrMj0g+ pIBVicDEYFesTC8YQNdsY5fF66+CrqxspkC6E/Rq4JgElrQisdOns4NEl99/WxcR V4hllPrec3diaclCOY6rnoFwAUYDe/ujKqrCoHmFfTBglU2ZDxOLiQe2qzwg9cbi qkVs9kp+F4pJz0mecoBNx0CKDkTMpPuDj7W3H5nS+fzrolm/y6HIki/TDPYR1q+Y 7uiSlJ7ANeCaza7RguRxZocjqY1S0v7BJfXO38W3w9D6/zcgYyCQu9tcmzeD4I83 vjY33ELYpb3qRO7mzufUcacQD8gJKD+lG/xSmjvA0ylDmSxqdVQ=
=cUj5
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
*

On Thu, May 15, 2025 at 12:36:02PM +0200, Philip Hands wrote:

Yes, changing that in the short term seem quite unwise, so I guess a >rewritten deb822 version of apt-setup, post-release, is what we'll need.

Has anybody talked to the apt maintainers whether they would be willing
to disable the deprecation warnings for the release, allowing one
(more?) cycle where the two formats are equal citizens? The deprecation warnings we had in the last months has stirred us up, the installer is
moving now, and the other packages as well¹, so the focus could be
shifted to a smooth release now and going back to the nag warnings after
the release?

Greetings
Marc

¹ eventually even ansible's apt module might support deb822 format


-- ----------------------------------------------------------------------------- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421

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

Cyril Brulebois <[email protected]> writes:

Philip Hands <[email protected]> (2025-05-15):

Cyril Brulebois <[email protected]> writes:

The problem is that apt-setup is currently working on a single
sources.list file, and having the 60local generator work on a different
one would likely mean reworking the debconf automaton quick a bunch. It
could also break the CI (mostly run/monitored by the other Roland and by >> > Phil, hence the explicit cc).

It seems to me that we need a new debconf setting, so that code to
migrate towards deb822 usage can be added without immediately breaking
things.

We could have e.g. `apt-setup/use-deb822-format` that might take values
like:

`no`:
everything should be in sources.list format.

Is that what we currently have, or are we already in a mixed state,
with some things generating deb822 already?

[ and yes-maybe, and yes ]

What I was trying to convey above is that absolutely everything is sources.list-centric, not just the format, but also that one particular
file.

The core of the debconf state machine (what I called automaton) is about writing a temporary file, passing it to apt-setup-verify after the

Ah, right, good point.

Yes, changing that in the short term seem quite unwise, so I guess a
rewritten deb822 version of apt-setup, post-release, is what we'll need.

[...]

'update':
use apt-get update to convert .list files

Assuming we're talking about `apt modernize-sources` here, that's the
only part that would seem easy to experiment with: we would only need
to control whether to post-process the generated sources.list file,
without starting with a big logic rewrite.

That's what I meant.

Cheers, Phil.
--
Philip Hands -- https://hands.com/~phil

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

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

iQIzBAEBCgAdFiEE3/FBWs4yJ/zyBwfW0EujoAEl1cAFAmglw5IACgkQ0EujoAEl 1cDxBA//W3X6xDfbmlH9MIKHYcSo/RBUxj/+NmfMfVbjVphuFyPheRbR5IRKZ/14 WDDw07dClhnbUbV3wOjD0ytSQ77YjVe0esvh4uMbX4mN0KUUtsF8SMkkaqT2Xw+a YCb4Mx1k9jZTK+fR5awr9axO7JQHPwmv+VeEHLO2z18yhOZEoYO4VK8pz8CB3zkk HFvrTOKjkwIIWZ/ZukZRBf7NO9Kg6TKJLgvreDRoT/KX+/KZ0K6IHUVon9trRklJ 2HZkR1Z4EDYh7sK1cvng67RuRhXcj9WqFiUXrvqpLYqQKW44o1Kay6lcM3sFuJOJ UCqvhb+jJaexzle2XUcqaEJqBbJFL0BwOgm6utH14/zEg+u14BKYicvSTct12708 qpOvgZ/X9/qTdM2g7uuLMWhZDN5su61LLd8yFYDzQSR1x4TRlIDQ2A8kXwBUsaSr cvppGFETCUptoKVkrbOdwmRAm58NTGpdjIej3z6ioJfh6FytPGXKr4L10CVBOOZf OJkhtOVnYeQ3VBcIdeg4uNRW2b5UqJlWuv8cOqbQVNdiQlHv6taAprrK+sTooNQq zCQnOPp0jM9kddutDJDnvw/2oWJFeCibP8SgZN7wy6HZxR8Nl7sS7h22VshTAEbo Pryh93DYQZXBjJITYYAoNNa3lHG400iCirafdW59sE84fNaR/Ws/+G
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway

Hi Marc,

Marc Haber <[email protected]> (2025-05-15):

On Thu, May 15, 2025 at 12:36:02PM +0200, Philip Hands wrote:

Yes, changing that in the short term seem quite unwise, so I guess a rewritten deb822 version of apt-setup, post-release, is what we'll need.

Has anybody talked to the apt maintainers whether they would be willing to disable the deprecation warnings for the release, allowing one (more?) cycle where the two formats are equal citizens? The deprecation warnings we had in the last months has stirred us up, the installer is moving now, and the
other packages as well¹, so the focus could be shifted to a smooth release now and going back to the nag warnings after the release?

You forgot the spoiler alerts! (That was my backup plan.)


After 10 days, I've only heard about Philip Hands (thanks!) with some idea about how to approach the transition, and we agreed it's actually really
not trivial… and of course you, Marc.

I might have scared people away, bored them to death, or something, but absolutely no-one commented on the proposed (admittedly vague) plan to
have apt-setup learn a little about deb822 sources…

… therefore, seeing how deep we are in the freeze, and how no-one's
actually working on this (and how dangerous it would be if anyone did):


Could apt maintainers please consider dropping the source modernization
hint for trixie? This is getting on users' nerves, and I can't see how
that could be fixed any time soon.

If you want the whole monologue session, it started here:
https://lists.debian.org/debian-boot/2025/05/msg00201.html

Thanks for your time!


Cheers,
--
Cyril Brulebois ([email protected]) <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

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

iQIzBAABCgAdFiEEtg6/KYRFPHDXTPR4/5FK8MKzVSAFAmgykukACgkQ/5FK8MKz VSBJKg/+JX9KvcYNtqe9poLB9EbQN4lGkkQp+jMmYKoBBSnP6M7Ownx7mhZ+rLLD NfFUE3g7j5kIoiiV9cq7l5J3uGlMxusceDuID+dsGFBeHyA8wv2IyM5o5ufjO3d+ swcYiOovemHuZqQJF2Fj3Ta9AX7zqfZcjqVYI0qiVS4gJKgadB4S0mE15RzbPR7W o9rQPAuuw5Q91/n/404AZDWX1lgQ2tzndg8xsxogKgih4bLWl7aGz07/8Jlk290G tqOI3LMqV9NvCgJibG4TGO+McNU1gSgPgVVCxREtLOQylPIvV/2qPir5H6f77zeF wZvGZbrhzv87OsawpUch/3grxO6bPgx7x6IwvhgALwanPpiHrsZRUrC7ofl6RUmW 9ZMG2pJ9Nq+1zenzLJc0wIwqDl+MQX/KYGknW/e9UdlzedjAlh0fuAm29aJtXf1a oD9KmNIo/cvY6CgajTWIKVxkbKB1+yxbqJ+2cq/z813Tb02b3udFMLM7srZQ16Eb lZF+uNhLcjLlNWxWEIanw2IrZuLH06WqRMmd9ZseUKAzypZFwn3SW1D/aqit8WjK cILHCEyoxYe/0Zwv03k1BkxKh6vpnjMGGgktEPfrt2jqD95zVLANL/p6z/2R9i8Y FXL4eIlhDpbd4DbG8gSahCqpN4kwVlwSrEDNq3Slm74QB0/eUv8=
=eFnK
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
*