Hello,
We're generating appstream data for rpmfusion packages nowadays to enable users to install packages from there using gnome-software and friends too.
Is there a way to automatically pull in the rpmfusion appstream data packages? We looked at weak dependencies, specifically backward dependencies. So, we added:
Supplements: appstream-data
to the rpmfusion appstream data spec files. However, based on my understanding of how these things work, this implies that the rpmfusion appstream data packages are pulled into a transaction only if the fedora appstream data package is being installed or updated too. Is that right?
If it is, is there a way to pull in rpmfusion appstream data if fedora appstream data is already installed on the system, and not part of the current transaction? Any suggestions on how this should be done?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On Tue, 2018-01-16 at 18:08 +0000, Ankur Sinha wrote:
Hello,
We're generating appstream data for rpmfusion packages nowadays to enable users to install packages from there using gnome-software and friends too.
Is there a way to automatically pull in the rpmfusion appstream data packages? We looked at weak dependencies, specifically backward dependencies. So, we added:
Supplements: appstream-data
to the rpmfusion appstream data spec files. However, based on my understanding of how these things work, this implies that the rpmfusion appstream data packages are pulled into a transaction only if the fedora appstream data package is being installed or updated too. Is that right?
I expected that it's not, but it is...
If it is, is there a way to pull in rpmfusion appstream data if fedora appstream data is already installed on the system, and not part of the current transaction? Any suggestions on how this should be done?
I would probably open bug against "libsolv" to behave as you would expect. - -- - -Igor Gnatenko
Hi Igor,
On Wed, Jan 17, 2018 10:52:50 +0100, Igor Gnatenko wrote:
to the rpmfusion appstream data spec files. However, based on my understanding of how these things work, this implies that the rpmfusion appstream data packages are pulled into a transaction only if the fedora appstream data package is being installed or updated too. Is that right?
I expected that it's not, but it is...
If it is, is there a way to pull in rpmfusion appstream data if fedora appstream data is already installed on the system, and not part of the current transaction? Any suggestions on how this should be done?
I would probably open bug against "libsolv" to behave as you would expect.
Thanks - I'll do that then. I wasn't quite sure of what the expected behaviour is but I'll take it up with upstream now.
The only way to really do this would be to make rpmfusion-release require it. However that will mean users have to download and install two packages to make it all work. That may break things for people who intentionally remove gnome-software and PackageKit
Dennis
El mar, 16-01-2018 a las 18:08 +0000, Ankur Sinha escribió:
Hello,
We're generating appstream data for rpmfusion packages nowadays to enable users to install packages from there using gnome-software and friends too.
Is there a way to automatically pull in the rpmfusion appstream data packages? We looked at weak dependencies, specifically backward dependencies. So, we added:
Supplements: appstream-data
to the rpmfusion appstream data spec files. However, based on my understanding of how these things work, this implies that the rpmfusion appstream data packages are pulled into a transaction only if the fedora appstream data package is being installed or updated too. Is that right?
If it is, is there a way to pull in rpmfusion appstream data if fedora appstream data is already installed on the system, and not part of the current transaction? Any suggestions on how this should be done?
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
On Thu, Jan 18, 2018 at 01:02:49PM -0600, Dennis Gilmore wrote:
The only way to really do this would be to make rpmfusion-release require it. However that will mean users have to download and install two packages to make it all work. That may break things for people who intentionally remove gnome-software and PackageKit
Does DNF process new Recommends? The -release package could Recommend it rather than Require it. In fact, couldn't it even do:
Recommends: (other-repo-appstream if (PackageKit or gnome-software))
On Thu, Jan 18, 2018 at 2:19 PM, Matthew Miller mattdm@fedoraproject.org wrote:
On Thu, Jan 18, 2018 at 01:02:49PM -0600, Dennis Gilmore wrote:
The only way to really do this would be to make rpmfusion-release require it. However that will mean users have to download and install two packages to make it all work. That may break things for people who intentionally remove gnome-software and PackageKit
Does DNF process new Recommends? The -release package could Recommend it rather than Require it. In fact, couldn't it even do:
Recommends: (other-repo-appstream if (PackageKit or gnome-software))
It does.
On Thu, Jan 18, 2018 at 02:21:35PM -0500, Neal Gompa wrote:
Does DNF process new Recommends? The -release package could Recommend it rather than Require it. In fact, couldn't it even do: Recommends: (other-repo-appstream if (PackageKit or gnome-software))
It does.
Thanks -- I thought so but was too lazy to check at the moment. So the above should do it, right?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On Thu, 2018-01-18 at 14:34 -0500, Matthew Miller wrote:
On Thu, Jan 18, 2018 at 02:21:35PM -0500, Neal Gompa wrote:
Does DNF process new Recommends? The -release package could Recommend it rather than Require it. In fact, couldn't it even do: Recommends: (other-repo-appstream if (PackageKit or gnome-software))
It does.
Thanks -- I thought so but was too lazy to check at the moment. So the above should do it, right?
Recommends are not different from Supplements. They still have same behavior as Ankur mentioned. We need to fix this rather than trying to workaround it (also given that proposed workaround won't work). - -- - -Igor Gnatenko
On Thu, Jan 18, 2018 at 08:47:49PM +0100, Igor Gnatenko wrote:
Recommends: (other-repo-appstream if (PackageKit or gnome-software))
Thanks -- I thought so but was too lazy to check at the moment. So the above should do it, right?
Recommends are not different from Supplements. They still have same behavior as Ankur mentioned. We need to fix this rather than trying to workaround it (also given that proposed workaround won't work).
Maybe I don't understand what you're saying. The problem Ankur mentioned is because he's trying to make one package supplement another, and that is only processed if that other package is updated. But here, putting it in the release package would make that release package be updated (by tautology -- an update is an update), and so the Recommends would be processed when people get that update. And if PackageKit or gnome-software is installed, they'd get the other-repo-appstream package pulled in too, right? (I guess that could also be "Recommends: other-repo-appstream if appstream".)
Sure, it'd be semantically nicer to have other-repo-appstream have a supplements relationship with the fedora appstream package in the package directly, but I don't think that having the release package recommend it is semantically wrong, either, so I don't think it's right to call this a "workaround", exactly. It's a different way to do the same thing which, hey, should work, right?
2018-01-18 20:21 GMT+01:00 Neal Gompa ngompa13@gmail.com:
On Thu, Jan 18, 2018 at 2:19 PM, Matthew Miller mattdm@fedoraproject.org wrote:
On Thu, Jan 18, 2018 at 01:02:49PM -0600, Dennis Gilmore wrote:
The only way to really do this would be to make rpmfusion-release require it. However that will mean users have to download and install two packages to make it all work. That may break things for people who intentionally remove gnome-software and PackageKit
Does DNF process new Recommends? The -release package could Recommend it rather than Require it. In fact, couldn't it even do:
Recommends: (other-repo-appstream if (PackageKit or gnome-software))
I wondered that too at one point. But It would lead to a race. The dnf .repo files would not be installed yet, and then the rpmfusion-*appdata couldn't be found. Maybe it will work on the next dnf transaction ? If someone could test ?
On Thu, Jan 18, 2018 at 09:38:13PM +0100, Nicolas Chauvet wrote:
Recommends: (other-repo-appstream if (PackageKit or gnome-software))
I wondered that too at one point. But It would lead to a race. The dnf .repo files would not be installed yet, and then the rpmfusion-*appdata couldn't be found.
Oh yeah, good point. :-/
Maybe it will work on the next dnf transaction ? If someone could test ?
Well, if you make a new version of the -release package every day.... :)
2018-01-18 20:02 GMT+01:00 Dennis Gilmore dennis@ausil.us:
The only way to really do this would be to make rpmfusion-release require it. However that will mean users have to download and install two packages to make it all work. That may break things for people who intentionally remove gnome-software and PackageKit
That would indeed not scale for cases where appdata are not relevant (others spins, server, headless multimedia, etc). I would like to avoid such miss-design where we would need to split into rpmfusion-*-release-workstation or other products. It would just move the problem without fixing it.
At which point it would be just easier to add the complementary appdata packages to install along the rpmfusion-*-release packages from our "Configuration" page.
One other method is to use Groups. The rpmfusion*-appdata files could be added to the appropriate comps group. That way it will be a matter to update the group after the releases packages are installed. This is similar than what can be done for multimedia with a "dnf groupupdate Multimedia". It would need to be updated manually (which I beleive was done automatically with earlier release but it's not the point anymore).