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.

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

Appdata rename #87

Merged
merged 2 commits into from
Jun 14, 2020
Merged

Appdata rename #87

merged 2 commits into from
Jun 14, 2020

Conversation

maxice8
Copy link
Contributor

@maxice8 maxice8 commented Jun 14, 2020

The rationale is stored in the commit's messages, most specifically in the first one

As pointed out by the official documentation:

https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#spec-component-location

/usr/share/appdata is a legacy path, that is kept for backwards
compatibility purposes.

The recommended path as per 2.1.2 Filesystem locations is:

/usr/share/metainfo/%{id}.metainfo.xml
As noted in the parent commit, this is to adapt to the expected path of
the AppStream specification.
@karlch karlch merged commit c982f32 into karlch:master Jun 14, 2020
@karlch
Copy link
Owner

karlch commented Jun 14, 2020

Thanks for pointing this out!

@maxice8
Copy link
Contributor Author

maxice8 commented Jun 14, 2020

Another thing, the specification says the id should be an unique identifier (so not just the name, otherwise forks will conflict).

So in the future it might be worth using something like org.karlch.vimiv.metainfo.xml

@maxice8 maxice8 deleted the appdata-rename branch June 14, 2020 10:40
@karlch
Copy link
Owner

karlch commented Jun 15, 2020

This also makes sense to me, although I am not very fond of adding my username in here. I guess it should also be unique between this legacy Gtk version and the newer qt port.

Maybe just org.vimiv.gtk.metainfo.xml and org.vimiv.qt.metainfo.xml and forks can just call themselves org.vimiv.forkid.metainfo.xml?

@maxice8
Copy link
Contributor Author

maxice8 commented Jun 15, 2020

well, most people use their name or the name of the organization like org.gnome (i have lots of those).

I also don't know what forkid should be

@karlch
Copy link
Owner

karlch commented Jun 15, 2020

I thought this could be up to the fork, e.g. if you would maintain one and like to call it after your username org.vimiv.maxice8.metainfo.xml.

If it is common practice to use the username though, I am not fully reluctant to org.karlch.vimiv.metainfo. Although there would probably still need to be some differentiation between the gtk and the qt port.

@maxice8
Copy link
Contributor Author

maxice8 commented Jun 15, 2020

well if i forked vimiv then it would be org.maxice8.vimiv. It is not obligatory but using your name or organization is what is most used.

could be vimiv-qt or vimiv-gtk ?

@karlch
Copy link
Owner

karlch commented Jun 15, 2020

If I read the standard you linked in the commit correctly, hyphens are discouraged. It seems like underscores could be valid, so maybe:
org.karlch.vimiv_gtk.metainfo and org.karlch.vimiv_qt.metainfo.
Or just dots:
org.karlch.vimiv.gtk.metainfo and org.karlch.vimiv.qt.metainfo.

This is somehow more complicated than expected 😃 Thanks for your help!

karlch added a commit to karlch/vimiv-qt that referenced this pull request Jun 16, 2020
* Rename to `org.karlch.vimiv.qt.metainfo.xml`. This is in conformity
  with the newer `metainfo` instead of the deprecated `appdata` and
  provides a more unique id compared to the basic `vimiv`.
* Fix a few URLs that pointed to the Gtk version.
* Extend information.

See the discussion in karlch/vimiv#87 for
further information.
karlch added a commit that referenced this pull request Jun 16, 2020
See the discussion in #87 for
further information.
@karlch
Copy link
Owner

karlch commented Jun 16, 2020

I have adjusted this in the two referenced commits for the corresponding fork. Thanks again!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants