rhughes: Would you be able to attend the fesco meeting tomorrow?

19:30-21:30 UTC in #fedora-meeting on irc.

It would be helpfull to have you there to provide input and information.

Of course. Thanks dude.

From the discussion last week it appeared a lot of FESCO hadn't had time to read all the threads etc. ... so I tried to put together a summary:

http://yum.baseurl.org/wiki/RepodataLocations

HTH.

Replying to [comment:3 james]:

From the discussion last week it appeared a lot of FESCO hadn't had time to read all the threads etc. ... so I tried to put together a summary:
http://yum.baseurl.org/wiki/RepodataLocations

Well, in the nicest possible way, a yum developer writing up a summary of positives and negatives isn't exactly impartial. In fact, I would go as far to say that your summary is horribly biased to the yum-based repodata solution without addressing many of the other key points. I kinda expected something like this to happen.

I'm also confused why you keep bringing up specspo. Specspo is a completely different thing that's maintained outside of the packages rather than taking the data from the upstream packages themselves. Please stop doing that.

In your summary, you've also forgotten:

• Having the ability to search without "downloading metadata...."
• Having the same solution that Suse and Ubuntu are using
• Providing functionality that KPackageKit is using right now
• Using code that is already written and debugged
• Translations for non-English speakers
• Pre-scaled and converted icons for applications like gnome-shell
• Popularity ratings, derived from comps, and submitted application usage stats
• The fact that the application data doesn't change for the lifetime of the distro
• The fact that Ubuntu has already been shipping the app-install data for over 6 years, and still continue to favour this over a repodata solution.
• Per-spin data, rather than treating all spins the same (e.g. KWrite is more important on KDE spin than on GNOME)
• A sane database schema (please, just compare the database design of pkgtags.sqlite to the app-install schema) that is easy for applications to query.

Also, please bear in mind that I'm not prepared to write all my upstream GNOME code for an inferior data-source, that's totally Fedora specific. I don't write any of my code to be tied to any one distro; my entire working ethic is to work with other distros and to create common shared specifications. I'm sorry if that disagrees with the mentality of "do this Fedora specific to increase market share" that I feel is totally misguided, because the Ubuntu Application Installer already makes us look like Windows 95.

At the moment I feel bullied by all the entire yum team and I'm really sick of dealing with all the political stuff. I want to design a slick user experience that doesn't suck, and at every turn I'm being blocked by different members of a team that wrote a command line package management tool that at some point became an API without any documentation except the code itself. Sorry to be blunt, but it's really how I feel.

So, in summary, FESCo please read the bugzilla entries and the mailing list thread and make up your own minds.

Well, in the nicest possible way, a yum developer writing up a summary of positives
and negatives isn't exactly impartial.

Of course I'm biased, if I touch the stove and burn myself I'm also biased against touching it again. repodata in packages has been tried, and it still hurts.

I'm also confused why you keep bringing up specspo.

Please read the article I linked to, it explains why I keep bringing it up.

In your summary, you've also forgotten
* Having the ability to search without "downloading metadata...."

Please read the summary I linked to, it explains why this isn't true.

• Translations for non-English speakers
• Pre-scaled and converted icons for applications like gnome-shell
• Popularity ratings, derived from comps, and submitted application usage stats
• Per-spin data...
• A sane database schema...

This ticket is just about distributing the data via. repodata or a package. The assumption is that the data will be "the same" either way.

Literally if you just take your fail.rpm and modifyrepo it into the repodata, and then rpm2cpio in PK clients ... I will stop complaining. I've already said I'm too tired to bother fighting you to do anything but the most minimal fix for the giant known problem. This is not about content.

• The fact that the application data doesn't change for the lifetime of the distro

Please read the summary I linked to, it explains why this isn't true.

So, in summary, FESCo please read the bugzilla entries and the mailing list thread
and make up your own minds.

If you have the time, I think it'd be great to read as much as possible and speak with as many people as possible. I just tried to put a summary together, to help out, as I knew that last week a few members had mentioned they hadn't had the time.

Replying to [comment:5 james]:

repodata in packages has been tried, and it still hurts.

Ubuntu have been doing this for years.

I'm also confused why you keep bringing up specspo.

Please read the article I linked to, it explains why I keep bringing it up.

specspo is a separate data package which became forgotten, unloved and not updated.

app-install-data is an automatically generated package from the upstream packages themselves. Updating it isn't a case of asking translators to translate eleventy-billion strings, it's one python command that sucks down the latest translations and icons that already exist in packages. It's automatic.

Putting the data in the Red Hat specific specspo package, rather than Red Hat specific metadata wouldn't have changed the fact that translators didn't want to update the content. The distribution method wasn't the problem.

This ticket is just about distributing the data via. repodata or a package. The assumption is that the data will be "the same" either way.

Right, so we're basically arguing over how the bits get transferred from the server to a client computer. I would argue they should be on the install media already, given the use cases we want and the small size of the data and icons.

Distributing it via a package allows us to:

• say in the GUI "vlc was found, but the source is not enabled. Enable it now? [yes] [no]"
• Merge the separate-per-repo databases into a system database, which can be directly queried by the front-end. We don't want frontends to open n (where n is typically 10-20) sqlite files and repeat the search on each one for sub-ms searches.
• do the search without going through yum or layers of PackageKit

• The fact that the application data doesn't change for the lifetime of the distro

Please read the summary I linked to, it explains why this isn't true.

I have, and I disagree. Take F13 as a good example. How many packages during the lifetime of F13 changed the primary package name (the one with the binary in, or at least where the new name didn't obsolete the old name) or their desktop id?. Try it for yourself and see how much "churn" creating a package->desktop database actually would be.

Richard.

Ubuntu have been doing this for years.

Ubuntu have also been distributing binary drivers, and lots of other stuff. And, like us with specspo, they may also not have known how bad an idea it was until they tried it. At which point they had stop energy.

I would argue they should be on the install media already,

repodata is on the install media ... without it we can't install.

Distributing it via a package allows us to:

• say in the GUI "vlc was found, but the source is not enabled. Enable it now? [yes] [no]"

I assume you aren't pretending we can ship repodata for rpmfusion etc? But, assuming legal allowed that, there's nothing stopping us having repodata for other repos in repodata (or, better, pointers to it etc). Again, this is not about the content.

• Merge the separate-per-repo databases into a system database

Again, read my summary and your own words ... anything can happen to the bits once they are on the computer. Merge them, load them into postgresql, whatever. This is about if the bits come from a package or repodata.
Yes, it's true that you need to check your "merged" data with all of it's components from the active repos. ... but that's true with packages too, except it's much harder with packages.

• do the search without going through yum or layers of PackageKit?

Again ... this has nothing to do with how the bits move.
From my summary:

• prestodelta doesn't use yum for anything other than "give me pointers to my bits"
• updateinfo has had users that don't use yum for anything other than "give me pointers to my bits".

[stuff always changes comment]
I have, and I disagree. Take F13 as a good example.

Ok, that's the newest distro. but meh. My first attempt was the obvious:

{{{
kdebase-4.4.2-1.fc13.i686.rpm -- GA
kdebase-4.4.5-1.fc13.i686.rpm -- current update
}}}

...diffstat on /usr/share/applications:

{{{
dolphin.desktop | 2 +-
kfind.desktop | 2 +-
kinfocenter.desktop | 2 +-
konsole.desktop | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
}}}

Having you two carry the fight from bugzilla into fesco trac is not at all useful. Please stop that.

Here are a few questions that I would like to see answered:

• In what way does the yum side define 'system' so that they can claim that installing a metadata package is 'modifying the system', but having yum download metadata and store it locally is not 'modifying the system' ?

• Is there anything preventing us from shipping the exact same data format that app-install is currently producing as repodata ?

Replying to [comment:9 mclasen]:

Here are a few questions that I would like to see answered:

• In what way does the yum side define 'system' so that they can claim that installing a metadata package is 'modifying the system', but having yum download metadata and store it locally is not 'modifying the system' ?

system modification == modifying the rpmdb.

• Is there anything preventing us from shipping the exact same data format that app-install is currently producing as repodata ?

no

AGREED: ship the package and agree to switch to the repodata version if/when

By a -2/+5 vote.

See http://meetbot.fedoraproject.org/fedora-meeting/2010-09-28/fesco.2010-09-28-19.30.log.html#l-179 for discussion.