AppData in RPMFusion

[Karel Volný]

Hi,

>>> The AppData metadata includes simple XML files with app descriptions, 
and
>>> a tarball of app icons.
>>> They can be distributed in the rpmfusion-free-release and
>>> rpmfusion-nonfree-release packages and will only add a couple more
>>> megabytes.
>>> 
>> 
>> from the user's point of view, even if it is only "a couple megabytes",
>> I'm not that happy if my precious resources are eaten up by 
>> things I do not use (while not that important on a desktop with 
unlimited
>> 100 Mbps internet connection, situation could be quite a different on 
some 
>> mobile device with pretty expensive mobile connection)
>
> That's why I suggested the approach currently taken by fedora of using a
> separate package.

now I'm confused, as you talked about putting it into *-release ...?

> For Fedora, the metadata + icons is 7.3MB according to yum info
> appstream-data. This would be much less for rpmfusion as rpmfusion has 
much
> less graphical applications. I don't consider 7.3MB a lot, in these days
> when storage is relatively cheap.

"relatively" is the key

what is cheap for you doesn't mean cheap for everyone - for sure, storage 
is much cheaper than x years ago, but many people keep those x years old 
computers as they still work and I don't see any reasons to force them to 
upgrade just for _optional_ features (in fact, they often switched to linux 
because Windows would force them to buy new hardware) ... maybe you change 
the furniture in your house (and the whole house?) each two years or so, 
but I keep it until it is broken beyond repair, and the same goes for 
electronic devices, they serve until they are able to serve ... I just hate 
those piles of old crap in our backyards, and those poisons in the 
air/water/soil emitted while manufacturing all the new crap ...

7 MB in a distro that has about 10 GB installed packages by default seems 
like nothing ... but I just find the attitude wrong - how did we got to 
those 10 GB when my (and hardly any other _home_ user's) productivity with 
the software hasn't increased since early nineties when I had about 30 MB 
for system and 50 MB for data (and in some cases, software that had 
output/workflows of the same quality as recent applications existed even in 
1980's ...)?

and it's not only the old hardware - another thing is miniaturization, it 
may be cheap to buy a new SD card, but if you have just one slot in your 
Raspberry Pi ...


similarly it goes for the bandwith as mentioned by Emmanuel - deltarpm is 
nice, but it has its own problems ...

if the estimated number of Fedora users is about 2.5 million, in theory, if 
1% of them would have pay-per-megabyte connection, the price would be 0.005 
cents per kilobyte on average[*], and deltarpm would manage to squeeze the 
update to 10 kilobytes, that's 2.5 M * 1% * 10 KB * 0.005 c = $1250 per one 
update

[*] I'm using the price of my mobile connection which I think is somewhere 
in the middle between developed and developing countries

of course, the number is completely made up, it's just for putting things 
into context ... it's cheap when you don't have to pay those $1250 weekly 
from your pocket (and no single person would care about 0.05 cents), right?
(... and no one cares how much that additional load costs the owners of 
download mirrors)


now let's go further ... if the typical installation has about 2000 
packages, what if there would be something "nice to have" for each of them 
that would increase the size of the package by those "cheap" seven 
megabytes?


dismissing concerns as "it is just one slice of salami, that's nothing" is 
IMO very misleading

we need to think in the global numbers - take UPS as an example: planning 
for one car doesn't make difference, planning for tens thousands? -
http://www.pressroom.ups.com/Fact+Sheets/Saving+Fuel:+UPS+Saves+Fuel+and+Reduces+Emissions+the+"Right"+Way+by+Avoiding+Left+Turns


so yes, provide new features, but think how to minimalise the negative 
impact and how to allow opt-out for those who do not need/want them (and 
even if it shouldn't be rather opt-in than default that needs to be 
opted-out)


>> from the developers point of view, I just wonder what will happen with 
the
>> icons packaged with the applications - are they going to be moved (i.e. 
a
>> lot of cross-dependencies created and some extra work as we'd need to
>> update two packages), or are they going to be duplicated (how will we
>> ensure that it wouldn't get out of sync), or what?
>
> The app icons for the appdata are extracted to
> /usr/share/app-info/icons/fedora-21/ - they are not installed in
> /usr/share/icons or similar, so no conflict or anything like that. They 
are
> always there when the metadata is installed.

so it will be duplicated ... rpm still cannot handle multiple ownership of 
a file?

> To ensure they "won't get out of sync" you need to do weekly/monthly
> rebuilds of the metadata and issue it as a regular package update.

"you" means me as the application maintainer, or someone else who will 
maintain AppData?

"regular package update" means AppData upgrade and not e.g. in my example 
qmmp?

>> p.s. somehow I cannot understand how do the translations work ...
>
> Each upstream project can implement their own way of getting translations
> to the XML files, using gettext and similar things.
> You can look in some GNOME projects if you want to see examples.
> gnome-boxes for example uses INTLTOOL_XML_RULE for this.

hm, I don't feel any wiser now :-(

I (or the upstream developer) can implement my own way of getting 
translations to the XML files only if I know how it should look like in the 
XML file?
- there doesn't seem to be any DTD available, and the "File specification" 
doesn't give a damn about different languages handling (except for the note 
that screenshots should be taken in English)

looking at the example:
http://people.freedesktop.org/~hughsient/appdata/example-intltool.patch

I see exactly _zero_ localised strings

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?

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."