Chocolate Doom - misleading description in software center (T5385)

[celticmagic]

Jason Yundt (#Jayman2000), 2017-12-26 14:51:11 UTC

Installing "Chocolate Strife" from the software center installs the package "chocolate-doom". This package includes Chocolate Doom, Heretic, Hexen, and Strife, not just Chocolate Strife.

[celticmagic]

Ikey Doherty (#ikey), 2017-12-26 14:53:43 UTC

This is a limitation in the current software center, it has a 1:1 mapping of package->appstream.
In the case of chocolate-strife it has 4 appstream files:

/usr/share/appdata/chocolate-doom.appdata.xml
/usr/share/appdata/chocolate-heretic.appdata.xml
/usr/share/appdata/chocolate-hexen.appdata.xml
/usr/share/appdata/chocolate-strife.appdata.xml

We'll need to figure out the best way to approach this in the SC..

[celticmagic]

Joshua Strobl (#JoshStrobl), 2019-09-25 16:49:56 UTC

[maikwoehl]

Looking at the pspec of chocolate-doom it is possible to make 4 packages out of it. The only shared files are:

<Path fileType="data">/usr/share/icons/chocolate-doom.png</Path>
<Path fileType="data">/usr/share/icons/chocolate-setup.png</Path>

but there is more:

<Path fileType="executable">/usr/bin/chocolate-server</Path>
<Path fileType="data">/usr/share/applications/chocolate-setup.desktop</Path>
<Path fileType="data">/usr/share/applications/screensavers/chocolate-doom-screensaver.desktop</Path>
<Path fileType="man">/usr/share/man/man6/chocolate-server.6</Path>
<Path fileType="man">/usr/share/man/man6/chocolate-setup.6</Path>

So referring each subpackage to it's main package as dependency?

Or should it rather be fixed in software center?

[maikwoehl]

Another idea would be to add a search in solus-sc that scans the repo for {tld}.{vendor}.{3..(n-1)} using get_apps_by_id.

Appstream docs mentions a convention that is also followed by chocolate-doom.

In this case it would be

• org.chocolate_doom.Hexen
• org.chocolate_doom.Strife
• org.chocolate_doom.Heretic
• org.chocolate_doom.Doom

So stripping the last bit can give us all that is to org.chocolate_doom. But that can also give false positives as org.chocolate_doom is {tld}.{vendor}. 😕

[joebonrichie]

If you want to play around with this

sudo eopkg it appstream-glib
eopkg fetch chocolate-doom
appstream-builder --packages-dir=. --include-failed -v

Read example-failed.xml, example-ignored.xml, and example.xml to see how appstream-builder manages it.

If you decide the split the package then each subpackage must have appdata a desktop file and an icon for appstream-builder to successfully generate appstream data for it.

[maikwoehl]

Okay appstream-builder is parsing the package name from the file and then assigning it to all three appstream metadata files. The icon is read from the *.desktop files, copied to cache and renamed.
So each package needs a copy of that files.

The screensaver is only for chocolate-doom.
The server-binary is dedicated and stand's for itself. The games do not need it to start a server on it's own. So it can be split apart, too.

There is a bug in constructing chocolate-setup.desktop file, because it does not point to one of the setup binaries compiled:

https://github.com/chocolate-doom/chocolate-doom/blob/539ef367c9982c5945f8608b63d2236eaecc929a/src/Makefile.am#L14C1-L17C55

An AUR packages has made this take on it:

# dedup all the *setup programs, make desktop file work
  rm "${pkgdir}"/usr/bin/chocolate-{heretic,hexen,strife}-setup
  mv "${pkgdir}"/usr/bin/chocolate-doom-setup "${pkgdir}"/usr/bin/chocolate-setup
  ln -s chocolate-setup "${pkgdir}"/usr/bin/chocolate-doom-setup
  ln -s chocolate-setup "${pkgdir}"/usr/bin/chocolate-heretic-setup
  ln -s chocolate-setup "${pkgdir}"/usr/bin/chocolate-hexen-setup
  ln -s chocolate-setup "${pkgdir}"/usr/bin/chocolate-strife-setup

The setup binary is only copied over in Makefile. So that is okay.

The man pages are also corrupted and do not have their correct binary name in it, because it only copied over:

https://github.com/chocolate-doom/chocolate-doom/blob/chocolate-doom-3.0.1/man/Makefile.am#L56

The man pages reference each other, but according to the man page docs it is allowed to reference man pages from another "projects":

      SEE ALSO
              A comma-separated list of related man pages, possibly
              followed by other related pages or documents.

              The list should be ordered by section number and then
              alphabetically by name.  Do not terminate this list with a
              period.

              Where the SEE ALSO list contains many long manual page
              names, to improve the visual result of the output, it may
              be useful to employ the .ad l (don't right justify) and
              .nh (don't hyphenate) directives.  Hyphenation of
              individual page names can be prevented by preceding words
              with the string "\%".

              Given the distributed, autonomous nature of FOSS projects
              and their documentation, it is sometimes necessary—and in
              many cases desirable—that the SEE ALSO section includes
              references to manual pages provided by other projects.

It is a lot of work to clean them up.

They have given each of the binaries a dedicated icon and cleaned up the man page mess on upstream. That's good.
Unfortunately no new release came out, but it is actively developed on the game.

Enough research for today...

[maikwoehl]

First shot, with a little bug in the desktop files: https://github.com/maikwoehl/solus-packages/blob/fix-chocolate-doom-appstream/packages/c/chocolate-doom/package.yml

[ermo]

@maikwoehl This is looking really good! If you need help or tips, don't hesitate to get in touch in the Solus Packaging channel on matrix. ^^'

[maikwoehl]

@maikwoehl This is looking really good! If you need help or tips, don't hesitate to get in touch in the Solus Packaging channel on matrix. ^^'

Hi @ermo,

I was completely zoned out the last months. I'm currently setting up my environment again and hopefully will start working again on this.