Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[Feature request]: Flatpakref could provide more fields to be set on origin remote #4512

Open
2 tasks done
mwleeds opened this issue Oct 25, 2021 · 0 comments
Open
2 tasks done

[Feature request]: Flatpakref could provide more fields to be set on origin remote #4512

mwleeds opened this issue Oct 25, 2021 · 0 comments
Labels
enhancement

Comments

@mwleeds
Copy link
Collaborator

mwleeds commented Oct 25, 2021

Checklist

  • I agree to follow the Code of Conduct that this project adheres to.
  • I have searched the issue tracker for a feature request that matches the one I want to file, without success.

Suggestion

#4499 pointed out that Flatpak wrongly uses the Title field of a flatpakref file, which is the title of the app it provides, as the title for the remote that gets created for it. This made me wonder, how can the remote title be specified by the flatpakref file? And the answer is, we don't currently have a way, except for the case where the repo specified using RuntimeRepo is also the repo providing the main ref, since in that case the title specified in that flatpakrepo file will be used. Admittedly that is the most common case, but perhaps we should also provide a way for the title (and possibly comment, description, icon, homepage, etc.) to be set in the case that the RuntimeRepo is a different repo than the one specified with Url. I think there are a few ways we could implement this:

  • Define a way for Flatpak to pull the title and other such info from the remote dynamically with an HTTP request. This has the advantage of being potentially a useful mechanism for other such metadata remotes want to provide to clients, and it would mean Flatpak could potentially fetch and utilize such data even for existing remotes rather than just new ones created fresh after this feature is added. But ultimately it's probably over-engineering and would not work for offline remote creation.
  • Add fields like SuggestRemoteTitle, SuggestRemoteComment, and so on for each missing field. This has the advantage of matching the current behavior of SuggestRemoteName but it's also a bit unweildy.
  • We could also add a field RemoteRepo that takes a flatpakrepo file, and just get all this metadata from there. We'd have to define which would take precedence if some pieces of metadata differ between the flatpakref and the flatpakrepo file, for the keys which are already supported in flatpakref files.
mwleeds added a commit that referenced this issue Oct 26, 2021
@mwleeds
Don't use app title from flatpakref as remote title
bab1680 
On two different code paths we were using the "Title" field in
flatpakref files as the title of a remote, which is incorrect. In most
cases, the remote added via the RuntimeRepo key will be the same as the
remote the app is from, so when the remote is added for the runtime, its
title will be correctly set using the Title value from the flatpakrepo
file and the app will therefore have an origin remote with a title set.
This is not currently true for flatpakref files that use
SuggestRemoteName=, see follow-up commit.

For flatpakref files that use a different remote than the RuntimeRepo,
we don't currently have a way for the title to be set automatically;
perhaps we should (#4512).

Fixes #4499
mwleeds added a commit that referenced this issue Oct 26, 2021
@mwleeds
Don't use app title from flatpakref as remote title
e3b1eff 
On two different code paths we were using the "Title" field in
flatpakref files as the title of a remote, which is incorrect. In most
cases, the remote added via the RuntimeRepo key will be the same as the
remote the app is from, so when the remote is added for the runtime, its
title will be correctly set using the Title value from the flatpakrepo
file and the app will therefore have an origin remote with a title set.
This is not currently true for flatpakref files that use
SuggestRemoteName=, see #4513

For flatpakref files that use a different remote than the RuntimeRepo,
we don't currently have a way for the title to be set automatically;
perhaps we should (#4512).

Fixes #4499
@mwleeds mwleeds mentioned this issue Oct 26, 2021
Merged
alexlarsson pushed a commit that referenced this issue Nov 15, 2021
@mwleeds @alexlarsson
Don't use app title from flatpakref as remote title
9dbd265 
On two different code paths we were using the "Title" field in
flatpakref files as the title of a remote, which is incorrect. In most
cases, the remote added via the RuntimeRepo key will be the same as the
remote the app is from, so when the remote is added for the runtime, its
title will be correctly set using the Title value from the flatpakrepo
file and the app will therefore have an origin remote with a title set.
This is not currently true for flatpakref files that use
SuggestRemoteName=, see #4513

For flatpakref files that use a different remote than the RuntimeRepo,
we don't currently have a way for the title to be set automatically;
perhaps we should (#4512).

Fixes #4499
mwleeds added a commit that referenced this issue Jan 4, 2022
@mwleeds
Don't use app title from flatpakref as remote title
f029d95 
On two different code paths we were using the "Title" field in
flatpakref files as the title of a remote, which is incorrect. In most
cases, the remote added via the RuntimeRepo key will be the same as the
remote the app is from, so when the remote is added for the runtime, its
title will be correctly set using the Title value from the flatpakrepo
file and the app will therefore have an origin remote with a title set.
This is not currently true for flatpakref files that use
SuggestRemoteName=, see #4513

For flatpakref files that use a different remote than the RuntimeRepo,
we don't currently have a way for the title to be set automatically;
perhaps we should (#4512).

Fixes #4499

(cherry picked from commit 9dbd265)
mwleeds added a commit that referenced this issue Jan 4, 2022
@mwleeds
Don't use app title from flatpakref as remote title
5337603 
On two different code paths we were using the "Title" field in
flatpakref files as the title of a remote, which is incorrect. In most
cases, the remote added via the RuntimeRepo key will be the same as the
remote the app is from, so when the remote is added for the runtime, its
title will be correctly set using the Title value from the flatpakrepo
file and the app will therefore have an origin remote with a title set.
This is not currently true for flatpakref files that use
SuggestRemoteName=, see #4513

For flatpakref files that use a different remote than the RuntimeRepo,
we don't currently have a way for the title to be set automatically;
perhaps we should (#4512).

Fixes #4499

(cherry picked from commit 9dbd265)
alexlarsson pushed a commit that referenced this issue Jan 11, 2022
@mwleeds @alexlarsson
Don't use app title from flatpakref as remote title
bd4fff1 
On two different code paths we were using the "Title" field in
flatpakref files as the title of a remote, which is incorrect. In most
cases, the remote added via the RuntimeRepo key will be the same as the
remote the app is from, so when the remote is added for the runtime, its
title will be correctly set using the Title value from the flatpakrepo
file and the app will therefore have an origin remote with a title set.
This is not currently true for flatpakref files that use
SuggestRemoteName=, see #4513

For flatpakref files that use a different remote than the RuntimeRepo,
we don't currently have a way for the title to be set automatically;
perhaps we should (#4512).

Fixes #4499

(cherry picked from commit 9dbd265)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@mwleeds