Your method uses the modernize-sources subcommand to check, but several versions will prompt without this subcommand. So, I think it's better to determine it by the apt version number.

In fact, even Debian and Ubuntu versions that are not EOL now support DEB822 sources, so perhaps there's no need for the check.

You also need to modify the if-elif blocks on here to facilitate migration from old repository, or else they will conflict.

but several versions will prompt without this subcommand

I have not bisected this what is the starting point of this notification?

In my experience It seems to me very connected to modernize introduction.

The missing Signed-By warning and migration consideration started with version 2.9.24, while the modernize-sources subcommand was added in 2.9.26.

In fact, even Debian and Ubuntu versions that are not EOL now support DEB822 sources, so perhaps there's no need for the check.

Do you think this is right?

I suppose it was introduced since APT 1.1

I will wait for the vscode team's official feedback about what kind of behaviour we want to adopt.

You did not change the gpg key location or embed it in the sources file as I mentioned.

You did not change the gpg key location or embed it in the sources file as I mentioned.

Cause I think this will require to handle also the removal case of the existing key.

So I think this could be introduced eventually in another PR.

Hi all, I finally got a chance to read through the PR.
I'm OK with the PR using the modernize-sources check, unless that check misses entire distributions that have apt stuck between 2.9.24 and 2.9.26 for some reason.
Could the PR also change the GPG key location to /usr/share/keyrings?

@rzhao271 Can you check now? Or we need to also migrate they key?

Saving the key to the new location looks good.
If the save is successful, I wonder whether it is safe to delete the old key from the old directory?

I confirmed the key is for packages.microsoft.com in general.
Could the postinst script also delete the key at the old location, /etc/apt/trusted.gpg.d/?
The postrm script also has to update CODE_TRUSTED_PART to point to the new location, /usr/share/keyrings.

It Is already pointing to that path. Do you want to add a removal?

Let me rephrase.

1. Could postinst.template also delete the key at the old location, /etc/apt/trusted.gpg.d/, once the key has been saved to the new location, /usr/share/keyrings?
2. Could postrm.template (which is not yet part of your PR) set CODE_TRUSTED_PART to the new location, /usr/share/keyrings?

Do you plan to make another review?

Not yet, because you haven't implemented either of #239390 (comment). I currently plan to merge the PR early next month.

Thanks for the addition, bhack!
I have been busy this week with some other items, meaning it might take me until next Week 1 aka debt week for me to test and then approve this PR.

I don't have a local env to test it so it is a bit of a black box PR that it rely on CI for verification.

No problem. The change also requires a custom build to fully test, and I have been creating custom builds behind the scenes and testing them on a Linux VM.

I have confirmed that this PR requires some more changes.

1. The script currently assumes that if the user has already written their own source file, that we don't have to move the key for them, either. In reality, if the key is in the old location, we should rewrite the user's source file anyway and move the key for them.
2. The postrm script currently removes the .list file, but it does not remove the new .source file. It should now remove the new .source file instead.

Edit: I have added more specific comments to the PR files themselves.

New apt updated the user message

Policy will reject signature within a year, see --audit for details
N: Some sources can be modernized. Run 'apt modernize-sources' to do so.

Confirmed with a custom Insiders build that the changes LGTM.