1 |
On 13 February 2012 21:35, Markos Chandras <hwoarang@g.o> wrote: |
2 |
> This field wont be useful to users but to GUI applications that want |
3 |
> to show a pretty name instead of a weird PN. It would be fully |
4 |
> optional but it would have a standard syntax. You can't use |
5 |
> <longdesription> for that to extract the real package name because |
6 |
> each developer use this tag in a different way. Same for description. |
7 |
> The proposed tag would have a single strict syntax, that is a single |
8 |
> string just for the real package name so it would be easily |
9 |
> extractable. And of course it would be fully optional. After all, it |
10 |
> is just an addition in metadata.dtd |
11 |
> |
12 |
|
13 |
|
14 |
I think it makes sense to also support there being multiple fields of |
15 |
this kind, because packages like libreoffice bundle multiple |
16 |
applications in the one. |
17 |
|
18 |
I'd propose a structure like |
19 |
|
20 |
<provides> |
21 |
<application name="Libreoffice Writer" binary="lowriter" |
22 |
description="A Word processing tool"> |
23 |
</application> |
24 |
.... |
25 |
</provides> |
26 |
|
27 |
|
28 |
You could have a proviso somewhere for multiple provides sections and |
29 |
each section being dependent on some atom match, but I think that's |
30 |
really over-engineering it. |
31 |
|
32 |
I thought about putting in stuff to allow for extra metadata for |
33 |
aliases and such to relate to what people are really looking for ( ie: |
34 |
people who are still wanting openoffice should get given libreoffice |
35 |
as a result ) but also smells of over-engineering and nasty messes. |
36 |
|
37 |
-- |
38 |
Kent |
39 |
|
40 |
perl -e "print substr( \"edrgmaM SPA NOcomil.ic\\@tfrken\", \$_ * 3, |
41 |
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );" |