[AppStream] <suggests>

Matthias Klumpp matthias at tenstral.net
Mon Jul 25 14:16:30 UTC 2016


2016-07-21 17:07 GMT+02:00 Lucas Moura <lucas.moura128 at gmail.com>:
> Hello,
>
> After speaking with the other GSOC student working on AppRecommender, this
> format may work for the work his is developing. His is work is to implement
> an strategy in AppRecommender that recommends packages to the user just
> after the user install a package. For example, if the user is installing vim
> and uses git a lot, AppRecommender can recommend vim-fugitive to the user
> after the install process is complete.
>
> Although this is not the usual scenario for AppRecommender, the suggests tag
> can work for this new strategy. However, if you think it is better to think
> of a new tag that encapsulates both approaches no problem. Either way, I
> have sent a MR containing the implementation of the suggests tag. I have
> implemented this feature like the first approach commented by Richard, using
> a single suggests tag, but his idea for the tag name makes sense to me, so I
> can change my implementation if that is necessary.

This is actually very good news, because it means we can likely get
rid of the more complicated and additional augmentation format
proposed in the other thread.
Having a dedicated merge component is much cleaner.
So, if you can live with something like that, we can move forward with
specifying the <suggestions/> or <suggests/> tag (whatever it will be)
and resolve this feature request.

Cheers,
    Matthias

> On Thu, Jul 21, 2016 at 11:40 AM, Matthias Klumpp <matthias at tenstral.net>
> wrote:
>>
>> 2016-07-20 16:58 GMT+02:00 Richard Hughes <hughsient at gmail.com>:
>> > Hi all,
>> >
>> > I've been trying to add <suggests> into appstream-glib. I've got a few
>> > questions:
>>
>> Please don't implement that yet - this feature doesn't really work
>> well for tools like AppRecommender, where apps are not the source of
>> the recommendeation, which reduces its usefulness to just a way for
>> upstream projects to recommend stuff.
>>
>> I would like to have some time to flesh out the details further,
>> especially in the light of the new AppStream curation metadata
>> proposal, which I am going to make.
>> The sprint is taking quite some of my time though, that's why I
>> haven't written down the proposal yet.
>>
>>
>>
>> > Is it supposed to be:
>> >
>> > <component>
>> >   <suggests type="upstream">
>> >     <id>org.example.Bar.desktop</id>
>> >     <id>...</id>
>> >   </suggests>
>> >   <suggests type="some-other-method">
>> >     <id>org.example.Baz.desktop</id>
>> >     <id>...</id>
>> >   </suggests>
>> > </component>
>> >
>> > or:
>> >
>> > <component>
>> >   <suggests type="upstream">
>> >     <suggest type="upstream">
>> >       <id>org.example.Bar.desktop</id>
>> >       <id>...</id>
>> >     </suggest>
>> >   </suggests>
>> > </component>
>> >
>> > To me the former makes sense, but the tag name doesn't -- in the other
>> > tags a plural means we nest singular terms. Would doing this make more
>> > sense:
>> >
>> > <component>
>> >   <suggest type="upstream">
>> >     <id>org.example.Bar.desktop</id>
>> >     <id>...</id>
>> >   </suggest>
>> >   <suggest type="some-other-method">
>> >     <id>org.example.Bar.desktop</id>
>> >     <id>...</id>
>> >   </suggest>
>> > </component>
>> >
>> > I don't see the need in a <suggests> parent, although I'd be up for
>> > that if you think it would make sense. Thanks!
>>
>> The idea was exactly what you proposed last, but as said, I am not
>> sure that having this is a good idea at time, before we have a
>> consistent story for how suggestions are handled in AppStream.
>>
>> Cheers,
>>     Matthias
>>
>> --
>> Debian Developer | Freedesktop-Developer
>> I welcome VSRE emails. See http://vsre.info/
>> _______________________________________________
>> AppStream mailing list
>> AppStream at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/appstream
>
>



-- 
Debian Developer | Freedesktop-Developer
I welcome VSRE emails. See http://vsre.info/


More information about the AppStream mailing list