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ý <kvo...@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 "+@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 ka...@jabber.cz
:: "Never attribute to malice what can
:: easily be explained by stupidity."
