| 1 |
Diego 'Flameeyes' Pettenò wrote: |
| 2 |
> - no need to replicate homepage data between versions; even though forks |
| 3 |
> can change homepage, I would expect that to at worse split in two a |
| 4 |
> package, or have to be different by slot, like Java; |
| 5 |
|
| 6 |
But also the need to replicate http://www.kde.org/ to metadata.xml of |
| 7 |
all KDE split ebuilds -- right now, this is set by an eclass. |
| 8 |
|
| 9 |
> - allows proper handling of packages lacking a HOMEPAGE; |
| 10 |
|
| 11 |
Could you elaborate a bit about how different is handling of an |
| 12 |
empty/uninitialized shell variable from an empty XML element? |
| 13 |
|
| 14 |
> - less data in metadata cache; |
| 15 |
|
| 16 |
Isn't it in the cache for some reason? Really, I'm just asking. |
| 17 |
|
| 18 |
> - users can check the metadata much more easily by just opening the xml |
| 19 |
> file or interfacing to that rather than having to skim through the |
| 20 |
> ebuild, the xml files are probably more user readable then ebuilds |
| 21 |
> using multiple eclasses; |
| 22 |
|
| 23 |
Haven't we already agreed that accessing ebuilds/... directly is broken |
| 24 |
by design? |
| 25 |
|
| 26 |
> - webapps like packages.gentoo.org would be able to display basic |
| 27 |
> information without having to parse the ebuilds or the metadata cache. |
| 28 |
|
| 29 |
Except for the ebuilds which still use the old format (that is 100% of |
| 30 |
the tree right now) |
| 31 |
|
| 32 |
Cheers, |
| 33 |
-jkt |
| 34 |
|
| 35 |
-- |
| 36 |
cd /local/pub && more beer > /dev/mouth |
Archives