| 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 );" |
Archives