Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=488968 James Antill <james.antill(a)redhat.com&gt; changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |james.antill(a)redhat.com --- Comment #2 from James Antill <james.antill(a)redhat.com&gt; 2009-03-06 12:39:50 EDT --- This should not be approved for Fedora. We have a mechanism for shipping repository metadata, and bundling it in packages is not it. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=488968 --- Comment #4 from Richard Hughes <richard(a)hughsie.com&gt; 2009-03-06 14:33:58 EDT --- (In reply to comment #2) This isn't repository meta data nor is it package metadata - this is application data. This is nothing like comps or specspo at all. This is also for functionality (the client side database) that is shared between distributions, and other distributions don't share our repomd or the same packaging tools. Please guys, don't just protest against this because it's not doing things the yum way. Putting icons and all translations in the yum repomd is not suitable unless you want to download large amounts of extra metadata every time a few packages change, and would add a large chunks of functionality to yum. I've got no intention of adding huge amounts of code to yum, as it already difficult to interface with yum using PackageKit and I really don't think yum should understand the concept of applications, rather than packages. yum is meant to be a package manager, not an application manager. I've been updating hal-info quite a bit in the last few years, and this has worked well for this sort of data. We cannot do this repo-side and use the mechanism in a cross-distro way. I've talked in depth with suse, ubuntu and foresight developers about this, and using yum in this way is not the right thing to do. Richard. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=488968 Jesse Keating <jkeating(a)redhat.com&gt; changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jkeating(a)redhat.com --- Comment #6 from Jesse Keating <jkeating(a)redhat.com&gt; 2009-03-06 15:58:20 EDT --- We already have one package attempting to gather things out of packages, specspo. It's horribly behind, often wrong, and generally useless. I'd rather not see Fedora repeat this mistake. If you want to be able to get information about available packages, we have repodata for that reason. If you think content will be too big, generate a file for each package that is "extra info". Clients can fetch just the extra info they care about. It'll require some engineering on the repodata creation side, and a lot of work to make sure it doesn't slow composes down, but that's the right place to put it, right along side all the other data about available packages. I will not support this package. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=488968 --- Comment #8 from Jeremy Katz <katzj(a)redhat.com&gt; 2009-03-06 16:38:31 EDT --- (In reply to comment #4) Richard -- how is the functionality shared by distributions? If I've followed what you've posted on your blog, then each repository has to have its own metadata (errr, "database") defining what applications are available within it. This then is told to the app-installer by registering it and saying "the database for this repo is over here". But if that's the case, why wouldn't it make sense to have the database registered by the repo itself? The main reason I can think of is that we're actually better off in allowing additional arbitrary metadata via yum than other package managers which are very hard-coded and can't do this sort of on-the-fly additional metadata :-) *grin* Isn't PackageKit a package manager by its very name? ;-) Really, the line between "application" and "package" is as much a historical accident as anything. They aren't one to one mappings, sucks... but so it goes. It gives us some nice things too. I fully agree that people in general want to be installing something to actually do something (an application) vs some arbitrary package/set of packages. But that doesn't mean that we have to go to a whole new level of abstraction and metadata generation/distribution to get there. As someone else mentioned, the difference is that hal-info isn't generated out of information about packages being shipped and rather is generated based on hardware. So it's more like hwdata than something like comps or specspo. Also, it seems somewhat a shame here that you've talked in depth with developers with every distribution *other* than Fedora :( -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=488968 --- Comment #10 from Richard Hughes <richard(a)hughsie.com&gt; 2009-03-06 18:02:30 EDT --- (In reply to comment #6) Does this mean this package review will be blocked? What about packages like smart and apt-rpm that do things differently to yum and the core distro? I'm not arguing this package should be installed by default, just be available to install. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=488968 --- Comment #12 from Richard Hughes <richard(a)hughsie.com&gt; 2009-03-06 18:11:44 EDT --- (In reply to comment #9) Sure, but we search in the locale, and hence we need that data upfront. Having icons download once per-user also seems painful (as the tools run as the user session, not root). -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=488968 --- Comment #14 from James Antill <james.antill(a)redhat.com&gt; 2009-03-06 23:49:52 EDT --- To respond to Bill: I somewhat agree, to the extent that PK can move forward it'll be to "standardize" higher level things that what it does currently. And I do think that's a much brighter future than what we have currently. However this I disagree with, to have "pkg install" and "pkg remove" in PK it didn't mandate how the backend functioned and I see no reason that Ubuntu can't drop metadata packages if they are insane enough to while we just use repo metadata. The "std." is in that everyone calls PK_lookup_application_data() or whatever ... not that each distribution has to merge to the same lowest common denominator. Yes, it's more work ... and it sucks that PK is writing everything 4 times, but then I've always said that. Indeed, but the state of specspo is a reason to reject this package not allow it through. No doubt specspo went live much faster due to it's implementation and I'm sure it will be more work for PK to have this feature implemented properly ... but look at the historical data on specspo. Yes it's still used as initially released, but it's still _barely_ working. "LANG=de_DE.utf-8 yum info kernel" has a translated description, but an en_US summary. "yum search 'Ein Betrachter und Editor'" still finds nothing. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=488968 --- Comment #16 from Richard Hughes <richard(a)hughsie.com&gt; 2009-03-07 03:56:44 EDT --- (In reply to comment #14) I don't understand why you keep referring to specspo. It's separate data about packages that doesn't really have a way of being tied to upstream. If the spec files were translated in CVS, and then specspo extracted the translations from the spec files (which are actively translated) and packaged it separately, then I would agree. But it's a separate project with no infrastructure tie in. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=488968 --- Comment #18 from Richard Hughes <richard(a)hughsie.com&gt; 2009-03-07 04:16:04 EDT --- (In reply to comment #11) This is the license: GPLv2+ and (LGPLv2+ and BSD) and EPL and LGPLv2 and (LGPLv2 with exceptions) and MIT and (GPLv2+ and LGPLv2+) and OFL and LGPLv2+ and (ASL 1.1) and (ASL 2.0) and GPLv2 and BSD and (Artistic 2.0 and GPLv2 and GPLv2+ and LGPLv2+ and LPPL and MIT and Public Domain and UCD and Utopia) and (GPLv2 and LGPLv2+) and (GPL+ or Artistic) and (MIT and GPL+ and TCL) and GPLv3 and (GPLv2+ and MIT) and (ASL 2.0 and MIT and BSD and CC-BY and LGPLv2+ and (AFL or LGPLv2+)) and GPLv3+ and (GPL+ with exceptions) and (LGPLv3 and LGPLv2+ and MPLv1.1 and BSD) and (GPLv2+ or OSL 2.1) and GPL+ and (OSL 2.0) and (QPL or GPLv2 or GPLv3) and (GPLv2+ with exceptions) and LGPLv3+ and CPL and WTFPL and (BSD and GPLv2+) and (SCRIP License) and (ASL 2.0 and MIT and BSD) and (BSD and MIT) and (Public Domain and MIT) and LPPL and (FTL or GPLv2+) and (GPLv2 with exceptions and BSD and CPL and Public Domain) and GPL and zlib and (GPLv2 with exceptions) and (GPLv2+ or Ruby) and (ASL 2.0 and W3C and Public Domain) and (MPLv1.1 or GPLv2+ or LGPLv2+) and (GPLv2 and LGPLv2) and (MIT or LGPLv2+ or BSD) and (GPLv2+ and GFDL) and GFDL and (Artistic 2.0) and (Public Domain) and (GPL+ and LGPLv2+) and (LGPLv2+ and GPLv2+ and GFDL) and libtiff and (QPL and (LGPLv2+ with exceptions)) and PHP and (GPLv2+ and GPLv2 and MIT) and ((CPL or GPLv2+ or LGPLv2+) and ASL 1.1 and MIT and Ruby) and OpenLDAP and (GPLv2 and Redistributable, no modification permitted) and (LGPLv2+ with exceptions and BSD) and (BSD and LGPLv2+ and (BSD or LGPLv2)) and ISC and (MIT with advertising) and (BSD and ImageMagick) and Artistic and (MIT and Lucida and Public Domain) and ERPL and (GPLv2+ and LGPLv2+ and MIT) and (LGPLv2+ or ASL 2.0) and (GPLv3+ and GPLv2+ with exceptions) and MPLv1.0 and CeCILL and MPLv1.1 and OpenPBS and OpenSSL and (ASL 2.0 and BSD) and Ruby and (LGPLv2 or Artistic clarified) and (Freely redistributable without restriction) and (GPLv2 and zlib) and (LGPLv2+ and CC-BY-SA) and Vim and AGPLv1 and (MIT and LGPLv2) and (MIT and GPLv2+) and (Redistributable, no modification permitted) and (Open Publication) and (CC-BY and Free Art and GPL+) and (LGPLv2+ and (BSD)) and (BSD and (GPLv2+ or Artistic or LGPLv2+) and LGPLv2) and (GPL+ and GFDL and CC-BY-SA and Public Domain) and (GPL+ or LGPLv2+ or MIT or MPLv1.1) and NetCDF and (LGPLv2 or MPLv1.1) and CC-BY-SA and CC-BY and (GPLv2+ and LGPLv2+ with exceptions) and (BSD with advertising) and (GPLv2+ or LGPLv2+) and (GPLv2 and GPLv3+ and MIT) and (Lucida and MIT and Public Domain) and (LGPLv2+ and GPLv2+) and (EPL and GPLv2 and LGPLv2) and (LGPLv2 and (LGPLv2+ or CPL)) and (GPLv2 with exceptions or CDDL) and (TMate License and ASL 1.1) and IJG and (Bitstream Vera and Public Domain) and (GPL+ or MPLv1.0) and IBM and TCL and (GPLv2+ or AFL) and ((GPLv2 or GPLv3) and GPLv2+ and LGPLv2+ and LGPLv2) and (BSD and LGPLv2+ and GPLv2+ and Public Domain) and (LGPLv2+ and LGPLv2+ with exceptions and GPLv2+) and (GPL+ and BSD and MIT and Public Domain) and (GPLv2+ or Artistic 2.0) and (Artistic clarified) and (ASL 1.1 and ASL 2.0 and W3C) and W3C and (LGPLv2+ or GL2PS) and (LGPLv2+ or Artistic) and (BSD and Python) and (GPLv2+ and Public Domain) and LGPLv3 and (LGPLv2+ and BSD with advertising and (LGPLv2+ and BSD with advertising)) and (LGPLv2+ with exceptions) and (MIT with advertising and GPL+ and GPLv2+) and (GPLv2 or BSD) and (GPLv2+ and GPLv3+) and SPL and AGPLv3 and Liberation and STIX and Baekmuk and (Vovida Software License 1.0) and (LGPLv2+ and GPLv2) and (GPLv2+ and LGPLv2+ and GFDL) and (GPLv2+ and Python) and (LGPLv2+ and W3C) and ZPLv2.1 and (Copyright only) and (CC-BY and CC-BY-SA) and IEEE and NGPL and (LGPLv2 with exceptions or GPLv3 with exceptions) and (GPL+ or Artistic 2.0) and (BSD and BSD with advertising and LGPLv2+ and GPLv2+) and (AMPAS BSD) and (GPLv2+ and GPLv2) and (GPLv2 and GFDL) and BitTorrent and (GPLv2+ and LGPLv2+ and MPLv1.1) and JasPer and (GPLv2 or Artistic) and (GPLv2+ or GFDL) and Python and (LGPLv2+ and GPLv2+ and MIT) and (GPLv2 and GPLv2+) and (GPLv3+ and LGPLv2+) and (Crystal Stacker) and (BSD and GPL+ and MIT) and (gnuplot and GPLv2) and (GPLv2+ or Artistic) and (libFoundation license) and CNRI and (BSD or LGPLv2+ or GPL+) and (EPL and ASL 2.0) and wxWidgets and (LGPLv2+ or CPL) and (MIT and BSD) and (GPLv2+ and GPL+) and zlib/libpng and (BSD with Advertising) and (GPLv2+ and GFDL and MIT) and (GPL+ and BSD) and (LGPLv2+ or MPLv1.1) and (GPLv2+ and BSD) and (GPLv2+ GeoGratis) and ((GPL+ or Artistic) and ASL 2.0) and (LGPLv2 and GPLv2) and (GPL+ and LGPL+ and ASL 1.0) and (GPLv2 and BSD and Public Domain and LGPLv2+ and GPLv2+ and LPPL) and (WTFPL or GPLv2+) and (Not licensed. See COPYING file for trademark permission.) and (BSD and MPLv1.1 and W3C) and ((LGPLv2+ or MPLv1.1) and ASL 2.0 and BSD and MIT and LGPLv2+ and CC-BY) and ((GPLv2+ or Ruby) and AFL) and Sendmail and (GPLv3+ with exceptions) and (GPL+ and GPLv2+) and ImageMagick and (LGPLv2+ or MIT) and (EPL and CPL) and (MIT and LGPLv2 and BSD with advertising) and (GPLv2 and GPLv2+ and LGPLv2 and MIT) and (Python or ZPLv2.1) and ((GPL+ or Artistic) or LGPLv2+) and (MIT and LGPLv2+ and Public Domain and BSD and Python) and (GPLv2+ and Free Art) and (SPL or LGPLv2+) and (LGPLv2+ and GPLv2+ and BSD) and (GPLv2+ and (LGPLv2+ or BSD) and ASL 2.0 and MIT) and (Python or ZPLv2.0) and (Artistic 2.0 or LGPLv2+) and (BSD and LGPLv2+ and MIT and SISSL) and (GPLv2 or QPL) and ((GPL+ or Artistic) and Public Domain) and (GPLv2+ and CC-BY-SA) and (GPLv3+ and LGPLv3+) and Giftware and (MIT and GPLv2) and MgOpen and (AFL and GPLv2+) and FTL and (GPLv2+ and LGPLv2 and (MPLv1.1 or GPLv2 or LGPLv2) and (LGPLv2 or BSD)) and (MIT and ASL 2.0) and (LGPLv2+ with exceptions and GPLv2+) and (AFL or GPLv2) and (GPLv2 or GPLv3) and (GPL+ or MIT) and SLIB and Teeworlds and (GPLv2 and GPLv3+) and NCSA and (MPLv1.1 or MIT) and (GPLv2+ and Hershey and MIT and OFL and Public Domain) and (Ruby or GPLv2) and (LGPLv2+ or SISSL) and (OSL 1.1) and (LGPLv2+ or W3C) and RiceBSD and (GPLv3+ with exceptions and GPLv2+ with exceptions and GPLv2+ and GPLv2) and MPLv1.1/GPLv2+/LGPLv2+ and LGPL and (GPLv3+ and GFDL+) and (GPLv2 and Bitstream Vera) and QPL and (GPLv2+ and LGPLv2+ and BSD) and Boost and (GPL+ or Ruby) and (GPLv3 and GFDL and BSD) and (LGPLv2 or EPL) and LGPLv2/GPLv2 and (ASL 1.1 and BSD with advertising) and (MIT and EPL) and (GPLv2+ and BSD with advertising) and (GPL+ and GPLv2 and GPLv2+ and LGPLv2+) and (GPLv2+ and Zend) and (GPLv2+, LGPLv2+, MIT) and Glide and (BSD and LGPLv2) and (GPLv2+ and GPLv2 and (GPLv2+ or MIT)) and (MIT and Public Domain) and (BSD or LGPLv2+) and (MIT or GPLv2) and Arphic and (GPLv2+ and GPLv3 and Green OpenMusic) and (BSD and GPLv2 and GPLv2+ and LGPLv2+ and MIT) and (QPL and LGPLv2 with exceptions) and (AFL or GPLv2+) and (GPLv2+ and GPLv2+ with exceptions) and (MIT with acknowledgement) and (GPLv2+ and GPL+ and BSD and MIT and Copyright only and IEEE) and (LGPLv2+ or GPL+) and (MIT and BSD with advertising) and (LGPLv2+ and MIT) and ZPLv2.0 and (QPL and LGPLv2 and LGPLv2+) and (LGPLv2 and MIT) and (Bitstream Vera) and (OpenLDAP and (Sleepycat and BSD)) and (BSD and Copyright only) and (LGPLv2+ and BSD with advertising) and (LGPLv3+ and GPLv3+) and (GPL+ and GPLv2+ and MIT and Redistributable, no modification permitted) and (LGPLv2 and GPLv2+) and (ASL 2.0 and zlib and ASL 1.1) and (ASL 1.1 and MIT) and (TCL and BSD with advertising) and (ASL 1.1 and ASL 2.0 and MIT) and (LGPLv2+ and VSL) and (BSD or GPLv2+) and (MPLv1.1 or LGPLv2+) and (ASL 2.0 or LGPLv2) and SISSL and (GPLv2 and MIT) and (GPLv2 and CC-BY-SA) and (BSD and GPLv2+ and Python) and (GPLv2 or LGPLv2 or MPLv1.1) and ((MIT and BSD and BSD with advertising) and (MIT and BSD) and GPLv2) and (GPLv3 or GPLv2 with exceptions) and (LGPLv2+ with exceptions and GPLv2+ and BSD) and (MIT and GPLv2 and GPLv3) and (GPLv3+ and Public Domain) and (GPLv2 and BSD) and (GPLv3 and LGPLv2+) and (GPLv3+ and BSD) and (GPL+ and LGPL+ and CC-BY and CC-BY-SA and CC-BY-ND and Public Domain) and (GPLv2+ and Redistributable, no modification permitted) and (GPL+ and LPPL) and (AFL or LGPLv2) and (GPL+ and zlib and MIT) and (Ruby or GPL+) and (GFDL and GPL+) and (Artistic 2.0 or LGPLv2) and ((GPL+ or Artistic) and BSD) and (GPLv2+ and LGPLv2 and LGPLv2+ and MIT and Public Domain) and LLGPL and (GPLv3 and MIT) and (GPLv3 and Public Domain) and (BSD and GPLv2 and IJG and MIT and Public Domain) and xinetd and (MIT with advertising and GPLv2+) and (EPL and LGPLv2) and ((GPL+ or Artistic) and (GPLv2+ or Artistic)) and (GPLv2 and GPLv2+ and LGPLv2+ and TCL) and (MIT and GPL+ and Copyright only and CC-BY) and (BSD and zlib and Boost) and ((GPL+ or Artistic) or BSD) and (BSD and ASL 1.1 and GPL+) and (GPLv3 and GFDL) and (GPL+ and OpenSSL) and mecab-ipadic and (GPLv2+ and MPLv1.1 and LGPLv2+ with exceptions) and (GPL+ or LGPLv2+ or MPLv1.1) and (CPL and IBM and GPLv2+) and (zlib and BSD) and (Public Use) and (Copyright only and Public Domain) and (GPLv2+ and LGPLv2+ and CC-BY-SA and CC-BY) and (ASL 2.0 and SPL) and (GPLv2+ and OFSFDL and (CC-BY-SA or GPLv2)) and (BSD with advertising and MIT and BSD) and (ASL 2.0 and MIT) and ((GPLv2 and GPLv2+ and LGPLv2+)) and (ASL 1.1 and W3C) and (LGPLv2+ or GPL+ or MPLv1.1) and (LGPLv2 and MPLv1.1) and CDDL and (BSD with advertising and zlib) and (GPLv2+ and LGPLv2+ and GPLv3+ and LGPLv3+) and (GPLv2 and LGPLv2 and BSD and MIT) and (mplus and BSD) and (EPL and CC-BY) and (LGPLv3 and CC-BY-SA) and (LGPLv2+ or GPLv2+ or MPLv1.1) and (MIT and BSD and ZPLv2.0 and Bitstream Vera and OFL) and (LGPLv2+ and (LGPLv2 or LGPLv3) and Public Domain) and (ASL 1.0) and (GPLv2 and Public Domain) and (GPLv3+ and MIT) and (GPLv2+ and CC-BY and CC-BY-SA) and (GPLv2+ and Adobe) and (GPLv2+ with exceptions and GFDL) and (GPLv3 or LGPLv3 or MPLv1.1) and (Intel ACPI) and (BSD and GPLv2+ and BSD with advertising) and (BSD or GPL+) and (ZPLv2.1 and BSD and MIT) and (GPLv2+ and LGPLv2+ and CPL and MIT) and (MPLv1.1 or LGPLv2) and (MPLv1.1 or GPLv2+) and (CPL or GPLv2+ or LGPLv2+) and (GPLv3+ and BSD and CC-BY-SA and AGPLv3 and (MIT or GPL+)) and (GPLv2+ and GPLv2+ with exceptions and Public Domain) and (GPLv2+ or LGPLv2+ or MPLv1.1) and (GPLv2+ or LGPLv3+) and (GPLv2+ and MIT and OFSFDL) and (BSD and BSD with advertising) and (LGPLv2+ and (LGPLv2+ and BSD with advertising)) and (GPLv2+ and LGPLv2) and (Public Domain and BSD and mplus) and (LGPLv2+ or ASL 1.1) and (BSD with advertising or GPLv2) and (Copyright 2006 Red Hat, Inc. All rights reserved.) and (LGPLv2 or GPLv2 or MPLv1.1) and (BSD and zlib) and (LGPLv2 or LGPLv3) and (zlib with acknowledgement) and (ASL 1.0 and BSD) and (MIT or AFL) and (GPLv2 and LGPL) and LGPLv2.1 and GPLv1 and (Copyright only and GPL+) and (Public Domain and LGPLv2+) and (BSD and GPLv2) and (zlib and GPLv2+) and (zlib and CPL) and (CC-BY and CC-BY-SA and Public Domain) and (MIT and GPLv2 and GPLv2+) and (GPLv2+ with exceptions or OFL) and TPL and Qhull and (GPLv2+ or Python) and (Teeworlds and MIT) and (LGPLv2+ and GPLv2 and GPLv2+ and GFDL) and psutils and (LGPLv2+ and wxWidgets) and Imlib2 and (GPLv3+ and GFDL and BSD and Public Domain) and (GPL+ and GPLv2+ and LGPLv2+) and (Artistic 2.0 or MIT or BSD) and ARL and (Public Domain and MIT and Python and GPLv2) and (GPLv2+ or CC-BY-SA) and (GPLv2 and GPLv2+ and BSD with advertising and Public Domain) and (MIT and LGPLv2+) and (APSL 2.0) and (GPLv2+ and MPLv1.0) and (GPLv2+ and LGPLv3+) and (Sleepycat and LGPLv2+) and (GPLv2+ and OFSFDL) and (Public Domain and GPLv2) and (zlib and CC-BY-SA and (GPLv3+ or Free Art or CC-BY-SA) and OAL and Public Domain and CC-BY and GPLv2+) and (ASL 2.0 and (GPL+ or Artistic)) and (LGPLv3+ or GPLv3+ or MPLv1.1) and (GPL+ and Public Domain) and (GPLv2+ and GPLv2 and LGPLv2+) and ((MIT or GPLv2+) and Redistributable, no modification permitted) and (MIT and (GPLv2+ or Ruby)) and (GPL+ or Artistic)) and (GPLv2 and Open Publication) and (LGPLv3 and CC-BY and CC-BY-SA and Public Domain) and (MIT and Python and ZPLv1.0 and BSD) and ((GPL+ or Artistic) and LGPLv2+) and CeCILL-C and ((BSD and LGPLv2+ and MIT and SISSL) and GPLv2+ and BSD with advertising) and (GPL+ and BSD and GPLv2+ and GPLv2 and LGPLv2+) and (BSD and LGPLv2+) and (LGPLv2 or Artistic 2.0) and GFDLv1.1+ and (LGPL+ or Artistic) and ZPL and (MIT and LBNL BSD and ZPLv2.0) and (Freely redistributable without restriction and BSD) and (GPLv2+ and Freely redistributable without restriction) and (GPL+ and LGPL+ and CC-BY-SA) and (GPLv2+ and BSD and GFDL) -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=488968 --- Comment #20 from Bill Nottingham <notting(a)redhat.com&gt; 2009-03-09 16:26:16 EDT --- Realistically, the license of the package would be the union of the licenses of the *icons* in the dependent packages, which is different than the union of the licenses of the packages themselves (and hopefully shorter). But that can't be sanely automated. (The fact that the license of the package ends up being this ludicrous should give some idea that this isn't really the best way to go about creating and deploying this...) (In reply to comment #11) How so? The problem is, essentially, that you want this delivered and updated in an incrementable format, as the data's going to be (generally) only additive, and in small chunks. Doing that as packages is pretty wasteful. Ideally, you'd have a server-side program that does this for you - you ask it for the differences between what you have, and what is the latest, and it sends it to you. But since all we have is yum, which is defined to not have any server components aside from raw transfer of files, any sort of metadata that wants to be deployed gets shoehorned into either a static metadata chunk, or a package. Neither of which is really appropriate here. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=488968 --- Comment #22 from Richard Hughes <richard(a)hughsie.com&gt; 2009-03-10 05:02:06 EDT --- (In reply to comment #21) Totally agreed. We would need some serious bandwidth and hardware for 1000s of concurrent users. The mirrors wouldn't also like thousands of tiny 40Kb files. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=488968 Alexey Torkhov <atorkhov(a)gmail.com&gt; changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |atorkhov(a)gmail.com --- Comment #24 from Alexey Torkhov <atorkhov(a)gmail.com&gt; 2009-03-16 11:52:46 EDT --- I like the idea keeping app-install database and icons not in package but as a kind of "extra info" that will could have benefits of caching and incremental updating (comment #6 and comment #7). I'm interested in implementing it as GSoC project. The exact way of generating and storing metadata should perhaps be first discussed with infrastructure people. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=488968 --- Comment #26 from Jesse Keating <jkeating(a)redhat.com&gt; 2009-08-14 11:57:10 EDT --- There is a terrible answer here, which is that you make users of PackageKit swallow a scheduled job that keeps all metadata fresh. Every few hours it just pulls down every single bit of metadata out there (think apt-get --update). That way whenever you go to use PackageKit, 9 times out of 10 you have the latest metadata and there is no need to go download anything new. And if there is a repo that is out of date (and we already have ways of discovering this very quickly/easily) the amount of new stuff to download will be quite small as compared to downloading for every repo. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=488968 --- Comment #28 from Rakesh Pandit <rpandit(a)redhat.com&gt; 2010-01-08 03:12:14 EDT --- *** Bug 488962 has been marked as a duplicate of this bug. *** -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=488968 James Antill <james.antill(a)redhat.com&gt; changed: What |Removed |Added ---------------------------------------------------------------------------- Flag| |needinfo?(mclasen(a)redhat.co | |m) --- Comment #30 from James Antill <james.antill(a)redhat.com&gt; 2010-09-07 12:03:16 EDT --- How is it different? specspo: . Metadata generated from packages. . Have to download everything at once. . Package updates change some of the metadata, often enough, thus. OOD. . Problems with multiple repos. (specspo only has one package). . Major problems with turning repos. on/off. "this BZ": . Metadata generated from packages. . Have to download everything at once. . Package updates change some of the metadata, often enough, thus. OOD. . Major problems with multiple repos. (specspo only has one package). . Major problems with turning repos. on/off. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=488968 --- Comment #32 from seth vidal <svidal(a)redhat.com&gt; 2010-09-07 12:35:09 EDT --- specspo _was_ pulled from the translated fields in the pkg spec files. it wasn't maintained separately. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=488968 --- Comment #34 from seth vidal <svidal(a)redhat.com&gt; 2010-09-07 12:45:18 EDT --- I'm confused - what does that have to do with anything? The point is - running another program to generate data then stuffing it into an rpm which we then ship out is a bad plan. Just as it was with specspo. Putting this data into the repodata is a better plan. ; -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=488968 --- Comment #36 from Richard Hughes <rhughes(a)redhat.com&gt; 2010-09-08 04:03:34 EDT --- (In reply to comment #34) This is the process in generating the data: * explode every rpm containing a desktop file (including selected deps where appropriate) * extract lots of data from the desktop file * copy the icons from the exploded root, converting and *resizing* where required * tarring up the icon tree * pushing the translations and desktop metadata into a sqlite database This takes 4 hours on my laptop to do for fedora, or 30 minutes for rpmfusion. This is not something we want to do every day, for data that probably should only be updated once or twice a release (Ubuntu . So, looking at positives and negatives, for putting it in a package: Package: * Allows us to ship the data on the media, so the user doesn't have to "download metadata" every time they open the application tool * Allows us to query the database directly, rather than convincing PackageKit [to download us the single chunk of metadata and then import the metadata into the system database, as root] * Means we share the *same tools* as Ubuntu, Suse and Foresight. * Means we don't have to patch KPackageKit which already depends on the system database. * Means we can merge rating stats from other external sources before we ship the data, e.g. the gnome3 application usage stats * It already exists, and someone is willing to maintain the package Metadata: * Allows us to ignore the fact that there are a few different licenses * Means we have to dedicate 4 hours per compose (possibly quicker if you have the rpms locally, but as we've discussed, the builders don't) * We have data changing daily that differs by only a few superficial entries * Means we can't use external data sources, for instance application usage stats * The app-install hooks in yum or PackageKit do not exist, and no-one is willing to write code for them. I've heard lots and lots of stop energy from the yum guys, but nobody has offered to write any code. Also bear in mind: Ubuntu has been shipping app-install-data FOR FIVE YEARS. It works for them as a package. Why do you think they shipped it as a package back then? And still now? They have a very similar infrastructure to us. The biggest point, and the most important from a user experience point of view is that we need to query the application database directly. If we make every query go through PackageKit, then through yum then we've killed our performance. Instead of getting responses back in the required 25ms for search-as-you-type we're talking about latencies of hundreds of milliseconds, or if yum has to check and download new metadata, *seconds*. This sucks and is simply not good enough. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=488968 --- Comment #38 from seth vidal <svidal(a)redhat.com&gt; 2010-09-08 09:52:20 EDT --- 1. the above is only true if you run the generator everytime and you don't cache anything. Outrageously naive, I think. 2. I'm going to talk to Florian about his implementation of the same - I seem to recall it taking substantially shorter amount of tim. 3. There is no requirement that we have to do it everytime the repo is changed. Only if it is changed substantively. Yah - they'll just have stale data. We don't have to import that metadata as root, now. Yum hasn't had to do that for quite some time. Moreover it's just a sqlite db. this definitely falls into the IBIWISI category considering we do not seem to be sharing ANY tools with any of these distros to speak of. A few? Really? And you don't need to do this at all if you extract the data from the pkgdb. And this is why you cache entries and update the db. We can use whatever data sources we want, in fact. I think what you've heard from us is years of experience cautioning you from chasing down a blind alley. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=488968 --- Comment #40 from Richard Hughes <rhughes(a)redhat.com&gt; 2010-09-08 10:51:38 EDT --- (In reply to comment #39) Yes, this would be good for FESCo to discuss. Seth (and the other yum guys) do not agree with the implementation, but as far as I am aware, this isn't reason enough to fail a review request. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=488968 --- Comment #42 from Bill Nottingham <notting(a)redhat.com&gt; 2010-09-08 11:17:40 EDT --- However, given that it's not obviously afoul of the packaging guidelines, this would appear to be a FESCo concern. (We ship many many things I think are bad ideas.) -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=488968 --- Comment #44 from Richard Hughes <rhughes(a)redhat.com&gt; 2010-09-21 04:19:35 EDT --- Also, I think it makes a lot of sense to whitelist or blacklist desktop files -- Ubuntu ask maintainers to submit applications manually so that the list is small and high quality, and that we can ensure apps are correctly categorized, and have things like reviews and screenshots. I don't think putting every application (package with desktop files) shipped in Fedora into an application installer is a good idea. i.e. you can't just run a script against pkgdb without some sort of manual control and merging different 'wads' of data. We probably might want different data for each spin. I think starting with the distro exploded tree is a good start, but the KDE spin is going to need different "ratings" on each application compared to the GNOME spin. And maybe a different definition of "application" is required for the server spin; that's fine with the app-install schema I'm suggesting. Also, this code exists now. It's ready to go. We've got upstream support from kpackagekit. We've got downstream support from the other distros that are watching us and certainly Ubuntu and Suse are willing to follow suit. This is probably very relevant to FESCo. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=488968 --- Comment #46 from Richard Hughes <rhughes(a)redhat.com&gt; 2010-09-29 17:11:48 EDT --- (In reply to comment #45) Such as...? Richard. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=488968 --- Comment #48 from seth vidal <svidal(a)redhat.com&gt; 2010-09-30 10:19:23 EDT --- Spot: Let's say we stuff the icons into a sqlite db in the pkgdb. And then we get that downloaded as metadata, do we need to have a special license for that since it is just a compilation and not a derivative work? Option two: only show icons of the apps the user has installed - since the icons would be on the local disk already. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=488968 --- Comment #50 from Tom "spot" Callaway <tcallawa(a)redhat.com&gt; 2010-09-30 10:34:56 EDT --- I think shoving the icons into the repodata and distributing them in a single bundle has the same problems as distributing them in a single RPM. Just thinking out loud here, but how about a situation where the icon is only shown when the user clicks on an item from a list to get more information. Then, that icon (and only that icon) is downloaded from something like the pkgdb if the network is up, and a category placeholder icon is used if it is not. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=488968 Adel Gadllah <adel.gadllah(a)gmail.com&gt; changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |adel.gadllah(a)gmail.com --- Comment #52 from Adel Gadllah <adel.gadllah(a)gmail.com&gt; 2010-10-02 14:13:14 EDT --- (In reply to comment #50) This (and the "only show for installed apps") suggestion both suck IMO. (from a user experience POV). Regarding auditing, as the license tag is generated by a script you'd have to audit the script (i.e check whether it works correctly) rather than checking every license by hand. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=488968 --- Comment #54 from Matthias Clasen <mclasen(a)redhat.com&gt; 2010-11-01 09:26:30 EDT --- I agree. We can't have user experience dictated by length of license field... -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.