Hi, Le samedi 19 août 2023, David Kalnischkies a écrit : > > Agreed. It would be nice to document that we can use regex here and > > that it actually makes sense to do so as most Debian release are actually > > composed of multiple repositories. > > The problem is that regex is NOT supported at the moment.
Urgh, and you did not complain that the release notes actually encourage users to do that? > It happens to work in most commands, but it e.g. doesn't in 'source'. > > Before we could (leaving alone the question if we should) document it > as supported, we would need to check all commands and fix those which do > not work with it. Nobody did in the last couple of years. > > So the only reasonable solution for this request so far is to document > it explicitly as not supported… which helps exactly nobody. Well, it's always nice to document the known limitations and thus invite users to prefer explicit pinning over usage of APT::Default-Release which is commonly used in a configuration file. > Step back and question why you want to use the option. There are > probably easier and simpler ways. Adding backports e.g. doesn't need > pinning at all (it comes by default with 100). Adding unstable to stable > might be a bad idea to begin with, but is certainly better dealt with > a pin against unstable rather than trying to catch all your "good" > "stable" repos in a regex to filter out the one bad "unstable" apple. I understand that but in my mental model, it was more like "as soon as you add other suites, make sure to document the preferred release with APT::Default-Release" instead of the opposite (i.e. make sure to pin down the repositories that you don't want to use by default). Clearly I have often used that when I added a newer release in sources.list (be it unstable/testing or just stable on an oldstable server or similar). Is there any difference of behaviour between reducing pin of alternate releases to a value < 500 vs increasing the priority of the desired release to 990? > In preferences the regex actually works and is documented, which is the > deeper reason behind APT::Default-Release working with regex or not as > certain commands can rely on the preferences infrastructure while > a command like 'source' can currently not and hence implements it > differently without support for a lot of things possible elsewhere. Maybe it can be documented as a limitation of the source command instead of refusing to acknowledging what works and what's used? > If you can come up with a list of use cases for that option (personally, > I don't see a good one) without too much by-catch we might be able to > implement a transition notice like I did for non-free-firmware. > Too late, too little, but at least it would prevent future misuse. Maybe you should deprecate the option in the configuration file and invite users to switch to preferences? I don't know what's best. It would still be nice to have a simple syntax that would match the -security repo, the -updates repo and the main repo for a given release... but maybe it should rely on a new "PartOfRelease" field in the various "Release" files or something like that. Cheers, -- Raphaël Hertzog
signature.asc
Description: PGP signature
