1 |
On Mon, 01 Dec 2008 00:12:23 +0100 |
2 |
flameeyes@×××××.com (Diego 'Flameeyes' Pettenò) wrote: |
3 |
> - no need to replicate homepage data between versions; even though |
4 |
> forks can change homepage, I would expect that to at worse split in |
5 |
> two a package, or have to be different by slot, like Java; |
6 |
|
7 |
You mean "no way of handling generated homepages, use conditional |
8 |
homepages, per version homepages or common homepages". |
9 |
|
10 |
> - allows proper handling of packages lacking a HOMEPAGE; |
11 |
|
12 |
Uh, we can do that using in-ebuild HOMEPAGE too. Just need to decide on |
13 |
a convention. |
14 |
|
15 |
> - less data in metadata cache; |
16 |
|
17 |
Entirely a non-issue. Heck, we want more in there, not less. |
18 |
|
19 |
> - users can check the metadata much more easily by just opening the |
20 |
> xml file or interfacing to that rather than having to skim through the |
21 |
> ebuild, the xml files are probably more user readable then ebuilds |
22 |
> using multiple eclasses; |
23 |
|
24 |
...or they can just use a decent too. Try 'paludis --query' for an |
25 |
example. |
26 |
|
27 |
> - displaying info about the package does not require parsing the full |
28 |
> ebuild file, with its eclasses; |
29 |
|
30 |
Uhm. It doesn't anyway, because of the metadata cache. |
31 |
|
32 |
> - extensible to provide more links than just the homepage (forums, |
33 |
> trackers, gentoo-specific documentation, ...); |
34 |
|
35 |
So's HOMEPAGE. You could extend the syntax to allow annotations: |
36 |
|
37 |
HOMEPAGE=" |
38 |
http://example.com/ |
39 |
http://forums.example.com/ [[ role = forums ]] |
40 |
http://www.gentoo.org/example [[ role = [ Gentoo specific docs ] ]] |
41 |
gtk+? ( http://gui.example.com/ [[ role = [ Optional GUI docs ] ]] |
42 |
" |
43 |
|
44 |
> - if we also move DESCRIPTION, search software can ignore everything |
45 |
> about ebuild parsing, and just use the metadata.xml files; |
46 |
> considering how many people actually use or used eix, it would make |
47 |
> sense to allow third-party applications to be able to search through |
48 |
> the tree; |
49 |
|
50 |
Except that any decent search client needs to be aware of masks, |
51 |
visibility and so on anyway. |
52 |
|
53 |
> - webapps like packages.gentoo.org would be able to display basic |
54 |
> information without having to parse the ebuilds or the metadata |
55 |
> cache. |
56 |
|
57 |
But they already display complex information. |
58 |
|
59 |
> - as much as people might think metadata is easier to parse than |
60 |
> anything, XML has one huge advantage: there are plently of parsers |
61 |
> for any language without having to actually write one, even as easy |
62 |
> as it can be, and it's easily interfaced with anything; I wrote a |
63 |
> simple XSL file that outputs the basic metadata details for packages |
64 |
> without having any parser or executable code but xsltproc (or any |
65 |
> other XSLT software), correlating data with herds.xml too; |
66 |
|
67 |
...or you could use a proper ebuild-aware tool that displays metadata |
68 |
details, including things like visibility. Again, paludis --query. |
69 |
|
70 |
> - it really is metadata, and it makes very little sense to need |
71 |
> parsing of eclasses and EAPI handling to get some data from a package |
72 |
> that is non-functional in nature and free form (just like |
73 |
> DESCRIPTION, and unlike LICENSE like Alec said), and that changes at |
74 |
> worse once each slot (unlike LICENSE that can change at any given |
75 |
> version). |
76 |
|
77 |
It isn't non-functional. |
78 |
|
79 |
> And the fact that you can ask the package manager for something is |
80 |
> for me not a valid reason to avoi moving something in a more |
81 |
> approchable place for other software. |
82 |
|
83 |
"More approachable" is a decent package manager API. If you had that |
84 |
you wouldn't need to mess around with XML APIs. |
85 |
|
86 |
-- |
87 |
Ciaran McCreesh |