One thing SeaMonkey lacks, however, is the sleek interface of Firefox and Thunderbird. The application is broadly based on other projects by the Mozilla project including the popular Firefox browser and the Thunderbird email client. SeaMonkey is a suite of Internet tools including a Gecko-based web browser, an email and newsgroup NNTP client and an IRC client which has many of the largest networks pre-configured. 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.Gecko-based web browser, e-mail, newsgroup, IRC chat, and HTML editing suite by Mozilla. desktop files?) Or is there some other solution? 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. If the appdata isn't provided by upstream anyway, there are no downsides. The appdata appears in GNOME Software and KDE Connect among some other places, and you will have the exact same problem there as here. 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.) 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. 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. Metadata should be provided by the package relevant to the metadata, because otherwise appstream generator generates wrong repository metadata. 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. Well, if that's the case, then I've updated the appdata tarball for SeaMonkey so that the browser application comes first. The order we get from Factory is kept the same I think. Perhaps I should raise a separate issue for this feature request? 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.) 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. (Generally speaking, such cases arise when the upstream developer provides a suite of interrelated applications and/or libraries in a single source package. 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. Maybe it would be a better idea to take all the appdata files and make separate entries for each of them. 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.
0 Comments
Leave a Reply. |