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

as-utils from appstream-glib need to be included in appstream #299

Closed
Conan-Kudo opened this issue Jan 29, 2021 · 5 comments
Closed

as-utils from appstream-glib need to be included in appstream #299

Conan-Kudo opened this issue Jan 29, 2021 · 5 comments

Comments

@Conan-Kudo
Copy link
Contributor

There are a number of utility functions in appstream-glib that do not exist in appstream, and without them, it'd basically impossible to migrate to libappstream.

For example, I cannot migrate PackageKit's libappstream-glib dependency to libappstream because as_utils_install_filename() is used in the DNF backend:

https://github.com/hughsie/PackageKit/blob/ed73aa6317595d2c2f1bda7990cbd64efb133f84/backends/dnf/pk-backend-dnf.c#L524-L545

@ximion
Copy link
Owner

ximion commented Jan 29, 2021

I will not blindly add all of as-utils, especially if nothing uses functions from it within AppStream, and also because there are a lot of duplicates.
The function you are referencing only copies a file from a to b though. appstreamcli has the same thing with its put subcommand.
I will look into adding it, but most likely without the libarchive parts to extract a tarball.

@Conan-Kudo
Copy link
Contributor Author

I will look into adding it, but most likely without the libarchive parts to extract a tarball.

That's a problem, though, since the icons and such are in a tarball.

@ximion
Copy link
Owner

ximion commented Jan 30, 2021

Well, you could just extract that stuff in dnf. But libappstream also has a vendor-specific function on Debian functions that just calls tar to unpack stuff, maybe that's good enough as well.

@ximion ximion closed this as completed in 30a9610 Jan 31, 2021
@ximion
Copy link
Owner

ximion commented Jan 31, 2021

I added this feature as API function now. I do think that the metadata should be installed and extracted by the package manager explicitly though, rather than using a function that relies on heuristics to determine some of its values.
But since appstreamcli could already do this (although only for metainfo files) there was no reason to not also add an API function for metadata installation.

By the way, @hughsie : Do you really want the appstream-glib variant of this feature creating world-readable directories? ;--)
=> https://github.com/hughsie/appstream-glib/blob/master/libappstream-glib/as-utils.c#L1157

@Conan-Kudo
Copy link
Contributor Author

I added this feature as API function now. I do think that the metadata should be installed and extracted by the package manager explicitly though, rather than using a function that relies on heuristics to determine some of its values.

There's almost no point in DNF doing it, since it can't really use the data for anything. That's why PackageKit does it instead.

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

No branches or pull requests

2 participants