SeaMonkey package incorrectly named "SeaMonkey Composer"

[logological]

The openSUSE Software page for the SeaMonkey package is incorrectly named "SeaMonkey Composer". It is also named this way in the search results, with the misleading description "Web Page Creation with the successor of the Mozilla Application". The SeaMonkey package contains not just a web page editor, but also a web browser and e-mail/news client. Most people use it for the browser and/or e-mail client.

I am not sure where this misleading name and description comes from—the RPMs on my system don't include them. If this isn't a problem with the openSUSE Software portal itself, please let me know where to report it.

[guoyunhe]

The display name is from AppStream, source code is seamonkey-appdata.tar.bz2 .

The description is from OBS configuration.

If you feel the naming or description is incorrect, contact the packaging team.

https://build.opensuse.org/package/show/mozilla:Factory/seamonkey

[logological]

The seamonkey-appdata.tar.bz2 file contains three different appdata files, one for the SeaMonkey Browser, one for the SeaMonkey Composer, and one for SeaMonkey Mail & News. How does the software portal decide which of these files to use for the description? IMHO it is incorrect to use any of them, since the SeaMonkey package contains all three applications. It should instead be using the description from the spec file, which attempts (rather poorly, though I will submit a fix for that) to describe the entire application suite. Is there any way of getting the software portal to show this generic description rather than one of the three appdata descriptions?

[agraul]

How does the software portal decide which of these files to use for the description?

The way I read the source code (first time looking into appdata related stuff), we look for all appdata-"apps" that fit the search term and then remove duplicates, keeping the first hit. The order we get from Factory is kept the same I think. For cases like this it does not play a big role, as, like you said, all three are not good enough.

Is there any way of getting the software portal to show this generic description rather than one of the three appdata descriptions?

At the moment appdata descriptions are used if available and the package description is a fallback.

I am not sure if this is a problem from our side or from the packaging. Intuitively I would say that each app should have its own package.

[logological]

The way I read the source code (first time looking into appdata related stuff), we look for all appdata-"apps" that fit the search term and then remove duplicates, keeping the first hit.

Maybe it would be a better idea to take all the appdata files and make separate entries for each of them. I don't think your solution of giving each app its own package is a good one; there are several apps in openSUSE (besides SeaMonkey) that are generated from the same package, and there are generally good reasons for this. (Generally speaking, such cases arise when the upstream developer provides a suite of interrelated applications and/or libraries in a single source package. The openSUSE community, or sometimes the developers themselves, have determined that it is convenient for users to be able to install the applications/libraries separately. Maintaining separate packages in OBS would be a pain, since this would involve a huge amount of duplication of manual effort and build time; it's easier to simply avail ourselves of RPM's ability to generate multiple related software packages from the same spec file.)

Perhaps I should raise a separate issue for this feature request?

The order we get from Factory is kept the same I think.

Well, if that's the case, then I've updated the appdata tarball for SeaMonkey so that the browser application comes first. I suspect that more users of SeaMonkey use the browser than the composer and mail/news client, so at least this way the most popular application in the suite gets shown in our directory.

[hellcp]

The way I read the source code (first time looking into appdata related stuff), we look for all appdata-"apps" that fit the search term and then remove duplicates, keeping the first hit.

Maybe it would be a better idea to take all the appdata files and make separate entries for each of them. I don't think your solution of giving each app its own package is a good one; there are several apps in openSUSE (besides SeaMonkey) that are generated from the same package, and there are generally good reasons for this. (Generally speaking, such cases arise when the upstream developer provides a suite of interrelated applications and/or libraries in a single source package. The openSUSE community, or sometimes the developers themselves, have determined that it is convenient for users to be able to install the applications/libraries separately. Maintaining separate packages in OBS would be a pain, since this would involve a huge amount of duplication of manual effort and build time; it's easier to simply avail ourselves of RPM's ability to generate multiple related software packages from the same spec file.)

Metadata should be provided by the package relevant to the metadata, because otherwise appstream generator generates wrong repository metadata. The package that ends up being associated with metadata is assigned by which package provides the metainfo file, there is no way around this, unless you want to argue over this with appstream folks upstream.

[logological]

Metadata should be provided by the package relevant to the metadata, because otherwise appstream generator generates wrong repository metadata. The package that ends up being associated with metadata is assigned by which package provides the metainfo file, there is no way around this, unless you want to argue over this with appstream folks upstream.

I'm not sure I understand your argument, but perhaps this is because we're using the same terminology differently here. Could you please indicate what you mean by "package" here? Are you referring to a particular RPM file, or to an OBS package (which generates one or more RPM files)?

[hellcp]

Metadata should be provided by the package relevant to the metadata, because otherwise appstream generator generates wrong repository metadata. The package that ends up being associated with metadata is assigned by which package provides the metainfo file, there is no way around this, unless you want to argue over this with appstream folks upstream.

I'm not sure I understand your argument, but perhaps this is because we're using the same terminology differently here. Could you please indicate what you mean by "package" here? Are you referring to a particular RPM file, or to an OBS package (which generates one or more RPM files)?

Repository metadata is generated for RPM packages, not for OBS packages

[logological]

So what do you consider the solution is for SeaMonkey, whose RPM packages a single executable file providing three distinct applications (browser, mail/news client, and composer), where each application has been given a separate appdata file? We need either three separate entries in the software portal, or else one single entry that covers all three applications. Should I replace the three appdata files with a single appdata file covering all three applications? (And in that case, are there any downsides to this? I'm not sure whether the appdata files are used by anything other than the software portal.) Or should I add a fourth appdata file to the archive that covers all three applications, and make sure that this appdata file is listed first in the tarball? (And again, are there any downsides to this? Does the OS use the appdata file in any way, or does it consult only the .desktop files?) Or is there some other solution?

[hellcp]

So what do you consider the solution is for SeaMonkey, whose RPM packages a single executable file providing three distinct applications (browser, mail/news client, and composer), where each application has been given a separate appdata file? We need either three separate entries in the software portal, or else one single entry that covers all three applications. Should I replace the three appdata files with a single appdata file covering all three applications? (And in that case, are there any downsides to this? I'm not sure whether the appdata files are used by anything other than the software portal.)

The appdata appears in GNOME Software and KDE Connect among some other places, and you will have the exact same problem there as here. If the appdata isn't provided by upstream anyway, there are no downsides.

Or should I add a fourth appdata file to the archive that covers all three applications, and make sure that this appdata file is listed first in the tarball? (And again, are there any downsides to this? Does the OS use the appdata file in any way, or does it consult only the .desktop files?) Or is there some other solution?

I don't think that's a reasonable solution, it's way too many layers and doesn't remove the "multiple appdata files per package" issue.

[logological]

The appdata appears in GNOME Software and KDE Connect among some other places, and you will have the exact same problem there as here. If the appdata isn't provided by upstream anyway, there are no downsides.

Is there any connection with .desktop files to consider? I know that every appdata.xml file needs a corresponding .desktop file. Will it be OK if I have a single appdata.xml file that links to the browser's .desktop file, and then two further .desktop files (for the mail/news client and the composer) that don't have a corresponding appdata.xml file?

[hellcp]

It's not a requirement to have appdata for every desktop file