If the packaging system wants to remove a package that came from
oldstable for dependency reasons, having oldstable sources listed
won't change that.

Some old packages (usually versioned libraries) are kept around forever
and don't cause any problems. They just sit on your hard drive doing nothing, because nothing uses them or depends on them.

The only time it's advantageous to keep oldstable sources is if you
need to *add* something from oldstable, typically a library, in order to
run some compiled binary program that you got from outside of Debian.
In these cases, you're on your own -- there's no support for it. Also,
going back just one release may not be sufficient. You'll often end
up trawling through the archive of past packages to find a compatible library, after you estimate what year the program was compiled.

Personally, I'd recommend replacing the oldstable sources with the stable sources (but don't use the word "stable" or "oldstable"; use the release name; I'm just using generalized language here). If it turns out later
that you need to add a package from bookworm on your trixie system, *then* you can add bookworm sources (or download the singleton package directly
from the archive). Otherwise, there's no need to continue downloading
lists of packages from multiple releases. It's just a waste of your
disk space and bandwidth.

Thank you very much for your very usefull informations. It answers all my questions and worries I had.

So, "best" way is to remove the old entries and use only trixie-related ones.

This litle question/issue is fully solved and can safely be closed.

I am looking forward to trixie and are very excited to it!

Best regards and thaky you all for your help!

Hans

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

Andrew M.A. Cater writes:

Use apt / apt-get options for safe upgrade - to upgrade the minimum
set of packages.

Log the output of the safe-upgrade command (normally just "apt upgrade")
and read the log before giving the next command.

Do an apt-get dist-upgrade / apt full-upgrade

And again, log the output.
--
John Hasler
john@sugarbit.com
Elmwood, WI USA

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

On Thu, Jun 19, 2025 at 05:27:55PM +0200, Hans wrote:

Thank you very much for your very usefull informations. It answers all my questions and worries I had.

So, "best" way is to remove the old entries and use only trixie-related ones.

Best way: Bring the system up to date on the old release - bookworm.

READ THE RELEASE NOTES

Change the sources.list to the new sources.list for trixie

Use apt / apt-get options for safe upgrade - to upgrade the minimum set
of packages.

Do an apt-get dist-upgrade / apt full-upgrade

Reboot to bring up the new kernel and OS

apt / apt-get autoremove

apt-get update again just to be sure :)

Did I already remind you to READ THE RELEASE NOTES?

It's probably not worth waiting until 13.1 point release - if the upgrade is going to work or fail, best find it out on day 1

All the very best, as ever,

Andrew Cater
(amacater@debian.org)

This litle question/issue is fully solved and can safely be closed.

I am looking forward to trixie and are very excited to it!

Best regards and thaky you all for your help!

Hans

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

On Thu, Jun 19, 2025 at 05:40:24PM -0400, Jeffrey Walton wrote:

[...]

It might be worth mentioning that if the package owns sources.list,
then you should not edit it. You should allow the package maintainer
to edit or replace sources.list. Place your changes in /etc/apt/sources.list.d/.

tomas@caliban:~$ dpkg -S /etc/apt/sources.list
dpkg-query: no path found matching pattern /etc/apt/sources.list

It seems no package "owns" sources.list. Besides, it's in /etc, so by convention it would be a conffile [1], i.e. Debian expects the sysadmin
to change things and copes with it.


Cheers
--
t

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

iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCaFT/cQAKCRAFyCz1etHa RpN2AJ9FS7+L7sVleYkt7DhQFVO6vrrKmgCfa2rohboPA1DntwuYij/dx7FNTvo=
=8DF3
-----END PGP SIGNATURE-----

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

On Fri, Jun 20, 2025 at 10:15:47 -0400, Jeffrey Walton wrote:

SSH config files are located in /etc, too. But admins are expected to
make changes to /etc/ssh/sshd_config.d/, and not /etc/ssh/sshd_config.

That's definitely false.

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

On Fri, Jun 20, 2025 at 11:06:51AM -0400, Jeffrey Walton wrote:

On Fri, Jun 20, 2025 at 10:37 AM Greg Wooledge <greg@wooledge.org> wrote:

On Fri, Jun 20, 2025 at 10:15:47 -0400, Jeffrey Walton wrote:

SSH config files are located in /etc, too. But admins are expected to make changes to /etc/ssh/sshd_config.d/, and not /etc/ssh/sshd_config.

That's definitely false.

You will absolutely lose your sshd_config when the package is upgraded
and you choose the maintainers version of the file.

No.

You will be asked, as for every conffile.

Of course, the .d construction is the recommended way these days,
but it is actually more important for *other* packages making
changes to the config. That's why it was introduced in the first
place.

Cheers
--
t

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

iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCaFV+mAAKCRAFyCz1etHa RrAMAJ4/k4pKz+/6lg4A4GjZagYlFwkBygCfUTUj348r+yvVWl/RKReS4rf9jCg=
=Xqs9
-----END PGP SIGNATURE-----

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

On Fri, Jun 20, 2025 at 11:40:59 -0400, Jeffrey Walton wrote:

On Fri, Jun 20, 2025 at 11:30 AM <tomas@tuxteam.de> wrote:

On Fri, Jun 20, 2025 at 11:06:51AM -0400, Jeffrey Walton wrote:

On Fri, Jun 20, 2025 at 10:37 AM Greg Wooledge <greg@wooledge.org> wrote:

On Fri, Jun 20, 2025 at 10:15:47 -0400, Jeffrey Walton wrote:

SSH config files are located in /etc, too. But admins are expected to make changes to /etc/ssh/sshd_config.d/, and not /etc/ssh/sshd_config.

That's definitely false.

You will absolutely lose your sshd_config when the package is upgraded and you choose the maintainers version of the file.

No.

You will be asked, as for every conffile.

Please don't do that selective quoting found in dumpster fires like
social media: "... and you choose the maintainers version of the
file."

You're missing the point. The point is you are ASKED whether you want
to keep your modified conffile or replace it with the maintainer's
version. The DEFAULT is to keep your modified file.

If you select to replace it, then sure, you'll "lose" your modifications, except that they're actually saved for you (your modified file is simply renamed), so you can still review it and manually edit the new file.

So, your argument is a straw man. You're saying that if you do a
sequence of bad things that are not the default, but something you've explicitly chosen of your own free will, that your life will be slightly
less convenient. Sure, that's true. But you could also just NOT do
those things.

Also, the OTHER point you got wrong is where you claim "admins are
expected to make changes to *.d". That's simply incorrect. Admins
are expected to make changes to sshd_config just like they've always
done, ever since long before *.d was invented. That's why the packaging
system ASKS you about your modified conffile and protects it with
multiple layers of insurance.

The entire system was designed and built around the idea that conffiles
would be hand edited and must be preserved.

That includes sshd_config.

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

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
On 2025-06-20 at 11:30, tomas@tuxteam.de wrote:

On Fri, Jun 20, 2025 at 11:06:51AM -0400, Jeffrey Walton wrote:

You will absolutely lose your sshd_config when the package is
upgraded and you choose the maintainers version of the file.

No.

You will be asked, as for every conffile.

That's why he said "and you choose the maintainer's version of the
file".

I imagine the idea is that of course people will choose the maintainer's version, because otherwise you wouldn't get the improvements (whether
new option settings for new features in the new upstream version, or new comments better explaining existing options, or new wordings of existing comments), and therefore they'll lose the changes that they made on
their own.

Of course, it could equally be argued that of course people will choose
their own version, specifically to avoid the problem of losing their own changes - even though that means they'll lose out on the improvements
from the maintainer's version.

Personally, what I do in response to such a prompt is to have it show me
a diff of the two files, and then if the changes involve losing any
settings want to retain, I have it give me a shell prompt (or use
another shell I have independently) to make a copy of the existing file.
I then let it install the maintainer's version, diff the old version
against that separately, and immediately use that diff as the basis for
editing the newly-installed maintainer's version to include the changes
I want to keep.

That's a bit of a pain, and the .d/ pattern avoids the need for it - but
if you were expected to either always install the maintainer's version
*or* always keep your locally-modified version, I don't see any reason
for them to have bothered with creating the entire conffile system in
the first place.

--
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


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

iQIzBAEBCgAdFiEEJCOqsZEc2qVC44pUBKk1jTQoMmsFAmhVgYMACgkQBKk1jTQo MmvRpg/7BDz8GHw6O1Vfn3HtxlOGTttyQP4Jr5knzXQb9VndEBQM6ZSBkK5OJ+A/ nJZf2XKie7z0XNv6trhM6uGyFV+wIhWRDRX3UAGUvry2mCFbbD0Z69+hxg0W/oAd lY9tHIAJkDJIiyqFz1uNwgMeHfpGDgdToU7qoJTCWIw0MFX3eQ1rI+1FPQ0wHrdk yFphYzM730t/4YPqGSxZgVYu93Imebezv7YWnd9h0ReZmJx7RwiJaDu83YHVbxWf 0ubcT+bA0wI0J2uKhAQrEBK+WT0O1ggKJiJ/R3Zw5EiVstyyGN0eshsLFckvztBM P41wlkikyKLS5o9qm1+aDEl72aeHXtaREwiG8dWc5Zn6MnuZB7uLPXRx2sM6gcsr uMEmJBxoouJf42S1AH/KI76pJVQGv2V9P/BcYXFHy9jZEjPjuNhDVf8VhaW9KjrQ BqHhCbwkcRfuIrUlgmbpMVaTklLburMZDs77I977PutewMR+mG2kmW6uvulH6mKp 3WqwkGzifH06JGhOFjfQYSVhXF5QDqJ+4kKJVi24muRq7QNskFQtS+xFNzwPih3c ZNJHNCnig/DdhgHnPe2bfKlUi9PRE7nmrn2TgDIBUSrfBrrnga+O2XZt/9wAWJsW NPAIVq0jmscBfu5RASGzGaSsBx/Y

On Fri, Jun 20, 2025 at 11:42:53AM -0400, The Wanderer wrote:

On 2025-06-20 at 11:30, tomas@tuxteam.de wrote:

On Fri, Jun 20, 2025 at 11:06:51AM -0400, Jeffrey Walton wrote:

You will absolutely lose your sshd_config when the package is
upgraded and you choose the maintainers version of the file.

No.

You will be asked, as for every conffile.

That's why he said "and you choose the maintainer's version of the
file".

[...]

Personally, what I do in response to such a prompt is to have it show me
a diff of the two files, and then if the changes involve losing any
settings want to retain, I have it give me a shell prompt (or use
another shell I have independently) to make a copy of the existing file.
I then let it install the maintainer's version, diff the old version
against that separately, and immediately use that diff as the basis for editing the newly-installed maintainer's version to include the changes
I want to keep.

That's exactly what I do, too. My take is, *if* you, as admin, feel
confident enough to change conf files, you should be able to understand
a diff and know what to do.

It doesn't happen *that* often.

Cheers
--
t

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

iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCaFWQqwAKCRAFyCz1etHa RmIlAJoDKKjqfBUm3D/hWQIE1gyoLK/4bgCcCxGTf1AIwjlksbI8tu74S+RnWyA=
=YPqz
-----END PGP SIGNATURE-----

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

Jeffrey Walton wrote:
...

Unfortunately, I cannot find a Debian specific article on
configuration directories. However, Red Hat has "Linux configuration: Understanding *.d directories in /etc,"
<https://www.redhat.com/en/blog/etc-configuration-directories>. Now
that we have configuration directories, admins are expected to make
their changes in them so:

Redhat is not Debian...


songbird

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

On Fri, 20 Jun 2025, The Wanderer wrote:

Personally, what I do in response to such a prompt is to have it show me
a diff of the two files, and then if the changes involve losing any
settings want to retain, I have it give me a shell prompt (or use
another shell I have independently) to make a copy of the existing file.
I then let it install the maintainer's version, diff the old version
against that separately, and immediately use that diff as the basis for editing the newly-installed maintainer's version to include the changes
I want to keep.

What I do is keep my current version, then when the upgrade is done,
create a new package that diverts the conffile for the debian package
and has my modified file (where I've forgotten to do this when I
originally needed to edit the file)

For example:
apt-cache policy local-xen-blockiscsi
local-xen-blockiscsi:
Installed: 1.7+tjw+r1
Candidate: 1.7+tjw+r1
Version table:
*** 1.7+tjw+r1 995
995 http://aptmirror.home.woodall.me.uk/local bookworm/main amd64 Packages
995 http://aptmirror.home.woodall.me.uk/local bookworm/main all Packages
100 /var/lib/dpkg/status

which has the fix I've proposed for https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1106420

It's debateable whether these should be conf files at all, they probably
ought to be in /usr/ somewhere.

N.B. for anyone trying this at home: https://www.debian.org/doc/debian-policy/ap-pkg-diversions.html

Do not attempt to divert a conffile, as dpkg does not handle it well.


Obviously, where it's possible to do it without diversions (other than completely replacing the package which is always an option) then you
should prefer that but for my case where there's only a handful of
conffiles which need editing and need their modifications preserved
around an upgrade, I do this. For example, on the machine I ran that
apt-cache policy command, replacing the modified conffile with the
maintainers conffile and rebooting will require console intervention to
fix as the VM that hosts the VPN endpoint necessary to connect remotely
will not start.

You do have to remember to review any maintainer changes just in case
there are required changes, but I find that less problematic then making
sure not to pick the wrong option while doing a dist-upgrade
particularly as the diversions themselves document what files you need
to check.

(The biggest issues I've found with diverting conffiles are if you try
to purge the diverting package where it doesn't leave things in a good
state and requires manual intervention to tidy up)

Tim.

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

On Fri, Jun 20, 2025 at 18:20:37 +0100, Tim Woodall wrote:

On Fri, 20 Jun 2025, The Wanderer wrote:

Personally, what I do in response to such a prompt is to have it show me
a diff of the two files, and then if the changes involve losing any settings want to retain, I have it give me a shell prompt (or use
another shell I have independently) to make a copy of the existing file.
I then let it install the maintainer's version, diff the old version against that separately, and immediately use that diff as the basis for editing the newly-installed maintainer's version to include the changes
I want to keep.

What I do is keep my current version, then when the upgrade is done, create
a new package that diverts the conffile for the debian package and has my modified file (where I've forgotten to do this when I originally needed to edit the file)

What I usually do is keep my current version, and then maybe some time
in the future, if I feel like it, I'll take a look at the *.dpkg-new
(or whatever it's called) file which contains the proposed new changes,
and see whether I want to attempt to merge those changes with mine.

Most of the time, however, I'll simply continue using my modified file
from umpteen versions ago, until something happens which makes that no
longer possible. Or until I discard that computer and replace it with
a new machine, at which point I'll need to start from a new version of
the file and recreate my local changes.

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

On Fri, Jun 20, 2025 at 12:12:09 -0400, Jeffrey Walton wrote:

Unfortunately, I cannot find a Debian specific article on
configuration directories. However, Red Hat has "Linux configuration: Understanding *.d directories in /etc," <https://www.redhat.com/en/blog/etc-configuration-directories>. Now
that we have configuration directories, admins are expected to make
their changes in them so:

Instead of editing this single file each time an application
is added or updated on the system, we separate the
configuration for each application to a specific file.

And this is all *new* stuff, right? Last 10 to 20 years?

Debian is much older than that. Debian's conffile policy is much
older than that.

The point is, you don't want to do gyrations on updates, like copying fragments of an old config into a new config.

Yes, it's a good idea in general. I won't argue that. It's also not
something that admins are expected to know about, or to do. Admins
are independent beings, who will usually continue doing the same thing
they've been doing for the last 40 years, which is editing the files
that they need to edit. The Debian conffile policy is built around
that practice.

In the specific case of /etc/ssh/sshd_config.d/, the man page is
pretty explicit:

Note that the Debian openssh-server package sets several options as stan‐
dard in /etc/ssh/sshd_config which are not the default in sshd(8):

• Include /etc/ssh/sshd_config.d/*.conf
• KbdInteractiveAuthentication no
• X11Forwarding yes
• PrintMotd no
• AcceptEnv LANG LC_*
• Subsystem sftp /usr/lib/openssh/sftp-server
• UsePAM yes

/etc/ssh/sshd_config.d/*.conf files are included at the start of the con‐
figuration file, so options set there will override those in
/etc/ssh/sshd_config.

To be completely transparent here, I'd never even *heard* of this until
you mentioned it earlier in this thread. This is completely new to me.
The fact that it's a Debian change is probably why I couldn't find it
in the OpenSSH web site's release notes, which is where I looked before
trying "man sshd_config" on Debian.

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

Hi,

On Fri, Jun 20, 2025 at 01:23:13PM -0400, Greg Wooledge wrote:

In the specific case of /etc/ssh/sshd_config.d/, the man page is
pretty explicit:

Note that the Debian openssh-server package sets several options as stan‐
dard in /etc/ssh/sshd_config which are not the default in sshd(8):

• Include /etc/ssh/sshd_config.d/*.conf
• KbdInteractiveAuthentication no
• X11Forwarding yes
• PrintMotd no
• AcceptEnv LANG LC_*
• Subsystem sftp /usr/lib/openssh/sftp-server
• UsePAM yes

/etc/ssh/sshd_config.d/*.conf files are included at the start of the con‐
figuration file, so options set there will override those in
/etc/ssh/sshd_config.

To be completely transparent here, I'd never even *heard* of this until
you mentioned it earlier in this thread. This is completely new to me.
The fact that it's a Debian change is probably why I couldn't find it
in the OpenSSH web site's release notes, which is where I looked before trying "man sshd_config" on Debian.

You may be putting too much stress on "a Debian change" here. There
isn't anything code-wise specific to Debian, only the fact that Debian
ships with the above configuration directives already there while the
upstream sshd_config doesn't.

I think the main reason why this note exists is to inform about the
behaviour of the .d directory, because OpenSSH's configuration is a bit unorthodox in that it is usually first-match-wins, i.e. the .d inclusion
has to happen at the top so that it is even possible to override
anything that appears below the inclusion in sshd_config.

So I think this note is important to inform about some directives that
may at first glance look like they needed to be removed or overridden in sshd_config but can in fact be overridden in a file inside /etc/ssh/sshd_config.d/.

Other than that, as far as I am aware the OpenSSH packaging on Debian
remains silent on where admins' local modification SHOULD be made, so I
am generally in agreement with you.

I also want to note that I agree that Debian's handling of modified
config files has always (for literally decades) been designed to support
and help with merging local modifications to config files. It has always
been much more advanced than support in other distributions.

There have even been some arguments that the relatively recent trend of providing .d directories and support for config fragment inclusion has
been added predominantly by software coming from distribution ecosystems
that lack decent support for config file upgrades, as their means of
handling that deficiency. I don't know how much I agree with that as,
even in Debian, it is an issue that it is forbidden by policy for one
package to meddle with the configuration files of another package, so
config file fragments were a way to solve that one.

But all that is to say that, we've been upgrading and merging old config
files for decades; some packages still do not support the concept of .d
config directories; even amongst those that do, in Debian there is
usually nothing saying where one SHOULD make edits, only that the
facility exists if you want it.

Personally I find the .d directory mechanism a mixed blessing. It is
handy for config management (by a tool) but it doesn't remove the need
to have to carefully check through any configuration changes *anyway*,
because I still need to know what I am or am not overriding! For example
if I override a setting in a config fragment, I don't want to miss when
the opposite setting gets added to the main distributed config file with
a warning next to it saying, "never change this, it will cause demons to
fly out of your nose".

As far as I am concerned the "correct" place to make changes is of local concern while understanding the trade-offs of the choice.

I think a better exemplar of this trend could be something like apache2
rather than openssh-server. In Debian we are all used to putting config fragments in the {conf,mods,sites}-available directories and then using
the tools to enable or disable those config fragments. I haven't looked
if Debian's package documentation says this is how it SHOULD be done but
in this package's case it has so many advantages that it would be a bit
odd not to. Nevertheless, I am sure some are still putting their edits
directly into /etc/apache2/apache.conf.

Thanks,
Andy

--
https://bitfolk.com/ -- No-nonsense VPS hosting

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