AppData in RPMFusion

[Karel Volný]

Hi,

Dne středa, 13. srpna 2014 10:32:58 CEST, Elad Alfassa  napsal(a):
> On Tue, Aug 12, 2014 at 4:52 PM, Karel Volný <kvolny at redhat.com> wrote:
>> now I'm confused, as you talked about putting it into *-release ...?
>
> Re-read my message please. I suggested two options: putting the metadata 
in
> the release packages *or* in a separate package.

I thought I've read that carefully ...

in the first e-mail, you've written:

"They can also be distributed in a different package ... but the user 
experience will suffer"

from which I boldly deduced that putting it into *-release is your 
preferred method

then you change to

"That's why I suggested ... using a separate package."

the fact is that now you're formally correct, you've really mentioned both 
options

but you've put one before the second and treated the second as inferior

and in the followup you turn 180 degrees and say you have reasons for the 
second

maybe I was too hasty to deduce that you'd prefer the method where user 
experience won't suffer, but I just don't like this style of communication 
where you say you're suggesting something you were arguing against, dude

> You update the appdata xml that is in your package, and at some point the
> appstream-data-rpmfusion package will get rebuilt either by automatic
> process or manual rebuild.
> "you" in this context refers either to rpmfusion infrastructure or the
> person who will manually rebuild the appdata package. Ideally it should 
be
> automated.
>
> As a packager, all you'd need to do is make sure you install your appdata
> xml to /usr/share/appdata

so, the application package will install a file that is of no use except 
"when building and composing distributions"[1] on which ocassion the 
contents will be copied to some database (probably in 
/usr/share/app-info/xmls [2]), that takes some more 3.3 MB / 769 KB 
un/packed[3]?

either I am missing something, or the design is heavily flawed

the cherry on top is (again [1]):

What happens if I don't ship this file?

The GNOME Software Center currently shows a nag message that the upstream 
project doesn't ship the additional data. Additionally, we will penalize 
apps that do not ship the extra metadata by showing them lower in the 
search results.

- cool, so the project is here not to help users, but to boost ego of some 
developers that have the urge to force others to do additional work to 
implement the one and only right_way(tm) of providing application 
description ... or how should I interpret the fact that they are going to 
make it harder for users to find what they search for?

[1] from http://people.freedesktop.org/~hughsient/appdata/

[2] guessing from 
http://people.freedesktop.org/~hughsient/temp/appstream-data.spec

[3] http://people.freedesktop.org/~hughsient/temp/fedora-20.xml.gz

>> what seems interesting is "+ at INTLTOOL_XML_RULE@", okay, so let's take a
>> look how does it work, let's go to homepage: 
http://freedesktop.org/wiki/
>> Software/intltool/
>> 
>> um, no single mention of any such macro, well, in fact, no documentation
>> at all? seriously? do I really have to read sources of that crap to get
>> basic understanding what does it do?
>> 
> Crap? Okay, dude, calm down, there's no call for name calling.

why not to call things the names they deserve?

good documentation is an essential part of good project

> Of course you don't see localized strings in the patch, you never put
> localized strings in the source files.

however, I do put it into the source tree (be the files *.po or *.ts or 
whatever) - and there is nothing like that in the example patch[4], that 
touches more files than just gcm-viewer.appdata.xml.in

[4] http://people.freedesktop.org/~hughsient/appdata/example-intltool.patch

> You do it in .po file. Regenerating the .pot file will make it have the
> strings from the appdata for translators to translate.

ok, so it is like xgettext[5] but it handles xml ...

[5] btw, https://www.gnu.org/software/gettext/manual/gettext.html

> If you want to see the RESULT, just cat 
/usr/share/appdata/totem.appdata.xml

okay, that explains the question - so the locales are not in some kind of 
*.mo files but directly inside the *.xml file distinguished by the 
'xml:lang="code"' attribute

it may seem trivial to you, but I've never worked with this before and I 
just can't get information out of vacuum - xml is only a container that can 
be used in many ways, and the sole possibility to add Language 
identification as per section 2.12 of the XML 1.0 recommendation doesn't 
imply anything about actual implementation (it could have been e.g. 
multiple files, one per language, as the abovementioned .mo works, or the 
translations could have been kept separately in message catalogs etc.)

> But these are things you need as an app author, not a packager.

I'd tend to disagree - if file(s) installation is involved then the 
packager should know how do the things work; he may even assist upstream 
(author) if the request to provide the file comes from downstream 
(distribution)

> This is not the place to discuss this thing, if you want you can send a 
mail
> to Richard or to the fedora devel list, I'm sure they'll be happy to 
assist
> you.

well, right

I'm just surprised that this is the first place I hear about it ... my 
primary role is not in development, so I'm not subscribed on devel, as I 
expect all important changes coming through devel-announce (maybe I just 
haven't paid enough attention?)

anyways, I've put my concerns to the ticket
https://fedorahosted.org/fpc/ticket/414#comment:31

> Furthermore, regarding your concerns about size, the appdata package for
> RPMFusion will be less than 3MB according to my calculations. It's small
> enough for everyone, we are in 2014, not 1995.

so, in 2014, the greenhouse effect and money spent in vain is of less 
importance than it was in 1995?

K.

-- 
Karel Volný
QE BaseOs/Daemons Team
Red Hat Czech, Brno
tel. +420 532294274
(RH: +420 532294111 ext. 8262074)
xmpp kavol at jabber.cz
:: "Never attribute to malice what can
::  easily be explained by stupidity."