On 2023-06-11 at 09:02, Greg Wooledge wrote: > On Sun, Jun 11, 2023 at 08:12:49AM -0400, The Wanderer wrote: > >> The same thing applies to those who track 'stable' by that name. >> Using the symbolic names for the releases, rather than the actual >> codenames, *is semantically different* and the tools *should treat >> it differently*. > > Using "stable" in your sources.list is idiotic, and you should not do > it. Ever. > > This is not a "use at your own risk" scenario, like using "testing". > That's OK for people who choose to accept the responsibility. > > Using "stable" is just a mistake. I do not understand why or how. If you want to transition from one stable release to the next when that "next" release is made, I don't see any better option for doing so, and I don't see how there's any downside to using the symbolic name 'stable' for that purpose. I also don't see how there's any difference between using the name 'stable' and using the codenames of each stable release, except in regard to the convenience factor - that is, whether the transition is picked up automatically, or whether you have to notice that the release has happened and manually modify sources.list to use the new name. I myself have sources.list entries for both 'stable' and 'testing' (as well as ancillary repositories for each, such as the -debug variants), have been running that way for a long time without related issues, and would not want to run with any other configuration. The only possible justification I can see for taking that position is the "it's dangerous to upgrade from one stable release to the next without reading the release notes first" thing, which I consider an ill-advised policy in the first place (you are *never* going to have everyone read the release notes before upgrading, any more than you are going to have people read other documentation before trying to use the thing which it documents, and it's a bad idea to design around the expectation that people will), and which in any case doesn't apply to people who are tracking testing+stable as I do. > If you're suggesting that the behavior of the tools should change in > some way -- something I am *not* advocating -- then the bext change > would be to make them *reject* any sources.list line that uses > "stable". Inform the user that the use of that label is too > dangerous, and that they must select a specific release to track. I could, maybe, perhaps, see an argument for prohibiting tracking stable, by that name, alone. However, a reject such as you are describing would also prevent the scenario I use for myself, which is effectively tracking testing with fallback to stable. If that scenario would also be worth rejecting... then that might be the final straw that confirms that Debian has in fact abandoned my use cases, and it really *is* time I found something else to move to, which would be a decidedly unhappy development. I would not necessarily object to the inclusion of a run-time *warning* about the use of such a line, especially not if there were a configuration option to disable the presentation of such a warning. I do, however, think it would be better for the tools to not require '--allow-releaseinfo-change' for repositories specified by such symbolic names - or at least to have a configuration option to not require such for that case. (My understanding is that there *is* a configuration setting to effectively enable that flag unconditionally in all cases, but I'm not sure I want to do that, and I haven't dug deep enough yet to find out whether there are more fine-grained versions of the configuration setting that might do something closer to the specific thing I want.) That said, I'm not particularly advocating for that change. What I *do* advocate, in this context, is that either the message printed by apt-get when it sees the mismatch should be changed to point to a document which explains how to approve the change, or the document to which it points - apt-secure(8) - should be changed to explain that. It is *boggling* that we have reached, if I'm not mistaken, now at least the *third* consecutive Debian release with this uninformative and unhelpful "see here for more" message. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw
Attachment:
signature.asc
Description: OpenPGP digital signature