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 <lolando@debian.org> (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 (kibi@debian.org) <https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant
Attachment:
signature.asc
Description: PGP signature