parse-info-all bool

[Harald Sitter]

It would be cool if parts had a `parse-info-all` key which enables parsing all data it can find.

Currently a developer needs to list all appstream files AND then also set the common-id on the app. This seems excessive. Since appstream files have well known locations it'd be far easier to simply enable extracting all meta data from a part.

So

```
name: sampleapp-name
adopt-info: sampleapp

apps:
  sampleapp:
    command: sampleapp
    common-id: com.example.sampleapp

  otherapp:
    command: otherapp
    common-id: com.example.otherapp

  thirdapp:
    command: sampleapp
    common-id: com.example.thirdapp

parts:
  sampleapp:
    plugin: dump
    source: http://github.com/example/sampleapp.git
    parse-info: [usr/share/appdata/sampleapp.metainfo.xml,usr/share/appdata/otherapp.metainfo.xml,usr/share/appdata/thirdapp.metainfo.xml,usr/share/appdata/fourthapp.metainfo.xml]
```

to

```
name: sampleapp-name
adopt-info: sampleapp

apps:
  sampleapp:
    command: sampleapp
    common-id: com.example.sampleapp

  otherapp:
    command: otherapp
    common-id: com.example.otherapp

  thirdapp:
    command: sampleapp
    common-id: com.example.thirdapp

parts:
  sampleapp:
    plugin: dump
    source: http://github.com/example/sampleapp.git
    parse-info-all: true
```

If full extraction isn't viable for a given piece of software the developer may still opt to do the explicit list, so nothing is lost. In the event auto extraction will be the desired thing (which to me seems to be case for probably just about all FLOSS desktop application) the explicit listing is entirely superfluous.

[Sergio Schvezov (sergiusens)]

How would we select which description and summary, at the least, to use from those discovered appstream files?

Also, I would suggest to change this if implemented to "parse-info-appstream-all: true" or to "parse-info-all: appstream" since parse-info is pluggable and can parse other forms of metadata.

[Harald Sitter (apachelogger)]

> How would we select which description and summary, at the least, to use from those discovered appstream files?

Good point. To be fair though, currently that isn't very clear either ;)

https://forum.snapcraft.io/t/control-which-common-id-the-adopt-info-comes-from/6091

I would imagine the easiest and most explicit way is actually adding a `common-id` attribute to the "root-level" attributes. e.g.

```
name: sampleapp-name
adopt-info: sampleapp # this is the part if I am not mistaken
common-id: org.foo.app # this is the appstreamid
apps:
  ...
parts:
  ...
```

One could argue adopt-info should actually be deprecated at that point. Assuming currently it is only communicating of which part to pick the first id in the parse-info list, which is wholly inferior to explicitly naming the desired id. The part the "master id" comes from isn't important, as the id must be unique across the entire snap anyway.

> Also, I would suggest to change this if implemented to "parse-info-appstream-all: true" or to "parse-info-all: appstream" since parse-info is pluggable and can parse other forms of metadata.

Sounds reasonable.

[Launchpad Janitor (janitor)]

[Expired for Snapcraft because there has been no activity for 60 days.]