On Sun 11 Jun 2023 at 09:46:49 (-0400), The Wanderer wrote:
> On 2023-06-11 at 09:34, Greg Wooledge wrote:
> > On Sun, Jun 11, 2023 at 09:20:41AM -0400, The Wanderer wrote:
> >> On 2023-06-11 at 09:02, Greg Wooledge wrote:
>
> >>> 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.
Maybe, but I don't think Debian would proscribe its use, as some
sysadmins might be happy to deal with the consequences as and when
the error and warning messages arise, for whatever reason. That
freedom is part of the open philosophy.
> >> 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.
> >
> > The issue is that an upgrade to a new stable release CANNOT BE
> > AUTOMATED by the tools. There are manual steps required, and these
> > are specific to each release, and to each user's unique system.
>
> While I recognize that automation is in some cases a hard problem, I
> also take the position that if you have a task that has to be carried
> out on a computer over and over the exact same way every time, and you
> are not automating it, you are doing it wrong.
>
> Thus, I push back - not absolutely, but fairly hard - against "cannot be
> automated".
>
> > One example of this -- among many! -- is the changing of sources.list
> > line syntax across releases. This time around, we got a new section
> > ("non-free-firmware") that had to be added to each line. Before that,
> > there was a change to the syntax of the security.debian.org line,
> > from "buster/updates" to "bullseye-security".
>
> And rather than putting in the design, etc., work to make these things
> happen automatically when they should (and not when they shouldn't), the
> developers gave up and punted it to the release notes. That could be
> acceptable if done rarely, but from what I remember seeing, it seems to
> happen *multiple times per release*.
So in this case they have to mindread the attitude of each sysadmin to
the different categories of non-free software. The same goes for
backports, which I suspect some people (like me) frequently remove as
unnecessary, after an upgrade to a new release.
> As I already mentioned, it's an insufficient solution - both because
> people will not read the release notes before upgrading, as I mentioned,
> and also because people who are tracking testing will encounter these
> changes before the release notes are written. For the most part, release
> notes should be for "important changes you might want to be aware of"
> and/or for getting more information on the details of changes, not for
> some kind of mandatory upgrade checklist.
>
> I might even argue that for changes like the two you cite, there should
> at minimum have been a tool provided (whether on a Website, or in a
> Debian package, if not something run automatically) which would make the
> necessary adjustments.
Complexity comes at a cost. Making transitional packages for easing
the upgrade of complicated substantive packages themselves seems
reasonable to expend effort on, and leverages the maintainer's
expertise. But I don't think that applies to two-yearly upgrades
that are trivial to implement in themselves, and where the precise
adjustments made depend mainly on the individual sysadmin's policy,
attitude to risk, and so on.
For example, when the message under consideration is received, some
admins tracking "testing" might continue to stick with that, others
might decide that all their hardware is now working well, and switch
to "bookworm" (the most stability), or they might follow the trailing
edge of future Debian development with "stable". And the same applies
across the range of distributions, except sid (and experimental,
not a distribution anyway). How would your automated system decide
which changes to make and when? How would it cope with the sort of
major upgrade changes made during the lenny/squeeze transition
(the paired kernel/udev conundrum).
Cheers,
David.
