Instructions with "repo" file in - https://code.visualstudio.com/docs/setup/linux#_rhel-fedora-and-centos-based-distributions

With https://kojipkgs.fedoraproject.org//work/tasks/3641/83543641/fedora-workstation-repositories-36-1.fc37.noarch.rpm I'm able to see the repository in Software and enable it from there. On the other hand I'm not able to find the VS Code through Software (but I'm able to install it with dnf). Is one able to find if AppStream data is available for that repository?

There's no AppStream data in that repository right now: https://packages.microsoft.com/yumrepos/vscode/repodata/

Does the RPM itself include a metainfo file? If so, we should reach out to them to tell them to generate the AppStream repodata and append it to their repositories.

Does the RPM itself include a metainfo file? If so, we should reach out to them to tell them to generate the AppStream repodata and append it to their repositories.

No, it isn't there and nothing is being done regarding to AppStream data is post scripts.

The current code is in https://src.fedoraproject.org/fork/tpopela/rpms/fedora-workstation-repositories/commits/vscode

Looks like VSCode should be shipping AppStream metainfo files in the RPM: https://github.com/microsoft/vscode/blob/main/build/gulpfile.vscode.linux.js#L154-L158

So it's just getting Microsoft to generate the repodata correctly.

Looks like VSCode should be shipping AppStream metainfo files in the RPM: https://github.com/microsoft/vscode/blob/main/build/gulpfile.vscode.linux.js#L154-L158

What I can see in that directory is only the icon - aka https://github.com/microsoft/vscode/blob/main/build/gulpfile.vscode.linux.js#L165 nothing else.

Wouldn't be vscodium more suitable? It's a patched version to remove proprietary stuff and disable telemetry. Fedora already does a similar thing with Chromium.

Wouldn't be vscodium more suitable? It's a patched version to remove proprietary stuff and disable telemetry. Fedora already does a similar thing with Chromium.

For within the repositories, yes, but we also give people an easy way to turn on third party repositories to get things like Google Chrome if they want. VSCode and Codium are no different in this regard.

The missing appstream data issue was already reported in upstream - https://github.com/microsoft/vscode/issues/141092 - Neal promised to contact @jperrin (maybe we will hear from him here, hi Jim!) about it.

Oh no. you're not dragging me back into... wait, where am I?

Yes, I've reached out to the internal developer team and will see what I can do to help fix this. Thanks for filing the github issue!

Per a conversation with @jperrin, I've filed gh#microsoft/linux-package-repositories#4 to generally raise the issue of missing AppStream repository metadata and provide a basic suggestion on fixing it.

Updating this issue with more information. There is an upstream issue in pulp which needs to be addressed as a part of resolving this for fedora. https://github.com/pulp/pulp_rpm/issues/2432

@rhughes , do you know if there's a way around this, if we're not able to get the appstream data into the repo containing the app? Could we include it in a different repo, for example? Any advice would be appreciated!

Well, I guess the obvious question is if we could use Flathub instead -- but maybe that's been considered already. We have to have some kind of link to the content otherwise we won't show the store, but I believe we used to do something like that for some of the codecs (e.g. mp3). The hack in fedora-appstream might work (e.g. copy the redistributable metadata manually) although I'm not sure if gnome-software treats the data in the same was as it used to. Sorry that's not more helpful.

Well, I guess the obvious question is if we could use Flathub instead

The experience using a Flatpak-packaged version of Visual Studio Code is quite different from using a RPM version of VIsual Studio Code because the Flatpak-packaged version gives a development version inside the Flatpak sandbox with no availability of the Fedora development environment.

[You can get a nice setup with vscode in a Flatpak + toolbox (https://github.com/owtaylor/toolbox-vscode) ... but would need official support from the VSCode side - and not everybody is going to want that in any case ]

We discussed this ticket along with #291 at yesterday's working group meeting.

Our understanding is that the "hack" referred to in @rhughes's comment is to distribute the appstream data as a separate package. This can result in the data can being out of sync with the app, which is something we don't really like.

As a next step, we've therefore agreed to reach out to the pulp developers to see if we can raise the issue of appstream support (via createrepo_c - see https://github.com/rpm-software-management/createrepo_c/issues/75). @tpopela has kindly said that he'll take care of that.

The email was sent and I'm waiting for reply.

Things started to move slowly and there's an ongoing communication in https://github.com/rpm-software-management/createrepo_c/issues/75

@jmracek would you mind taking a look at https://github.com/rpm-software-management/createrepo_c/issues/75 again?

Thanks for the ping

The working group touched on this issue during last week's meeting (25 October 2022). It seems that it's still blocking on https://github.com/rpm-software-management/createrepo_c/issues/75

Workstation WG is currently not in a position to consider requests for repos that don't provide appstream metadata, and Microsoft cannot provide it due to createrepo_c#75. Accordingly, let's reject this request for now.

If createrepo_c#75 is fixed in the future, then we can reopen, but in the meantime this is just not actionable. Same as #291.