| 1 |
On Sun, Nov 30, 2008 at 8:53 AM, Peter Volkov <pva@g.o> wrote: |
| 2 |
> В Вск, 30/11/2008 в 17:09 +0200, Serkan Kaba пишет: |
| 3 |
>> Peter Volkov yazmış: |
| 4 |
>> > Also sometimes it's useful to have different HOMEPAGE for different |
| 5 |
>> > versions. |
| 6 |
>> > |
| 7 |
>> > And in general, Diego. What are you trying to improve with this change? |
| 8 |
>> > The original intention was to separate common information from all |
| 9 |
>> > ebuilds into metadata.xml. But obviously, HOMEPAGE changes from ebuild |
| 10 |
>> > to ebuild. Now if intention is separate some information from ebuild |
| 11 |
>> > into metadata.xml then, please, tell me what is the criterion for such |
| 12 |
>> > information? Why not LICENSE? Currently I don't think this change worth |
| 13 |
>> > our efforts... |
| 14 |
>> > |
| 15 |
>> LICENSE should definetely be avoided to be defined per-package. Upstream |
| 16 |
>> may decide to relicense new version of packages. |
| 17 |
> |
| 18 |
> Well, actually the reason we should avoid LICENSES in metadata.xml is |
| 19 |
> that it's used by portage and possibly at some point of time it'll be |
| 20 |
> possible to filter packages based on LICENSE. But the general question |
| 21 |
> still stands: what is the criterion we should use to separate variables |
| 22 |
> from .ebuild into metadata.xml and what are the benefits of such |
| 23 |
> separation? |
| 24 |
|
| 25 |
Going to randomly jump in, partially because I have a comment here. |
| 26 |
|
| 27 |
Ebuilds are already filterable by license in portage, Marius |
| 28 |
implemented that a while ago. I'm sure the other package managers |
| 29 |
have similar filtering abilities. |
| 30 |
|
| 31 |
To the general thread: |
| 32 |
|
| 33 |
Anecdotal evidence is stupid. No one cares if one of your packages |
| 34 |
has a different homepage per version. |
| 35 |
Go scan the tree and show how many packages have this problem and we |
| 36 |
can at least have useful data then (X% of the tree). |
| 37 |
|
| 38 |
Zac, if we ask you to prioritize elibs, how long do you think |
| 39 |
implementation will take? |
| 40 |
|
| 41 |
Diego, What are the concrete benefits of your proposal? |
| 42 |
|
| 43 |
All, |
| 44 |
|
| 45 |
It is important to note that we are a large diverse group of folks and |
| 46 |
when you propose global changes you have to be willing to sell your |
| 47 |
idea to a large number of folks or implement it alone. Coming to a |
| 48 |
list with no data and no real 'pros/cons' data for your idea isn't not |
| 49 |
a good way to sell it to anyone. |
| 50 |
|
| 51 |
However cool the idea is, it is *never* obvious to everyone. It is |
| 52 |
never cost free. |
| 53 |
|
| 54 |
-Alec |
| 55 |
|
| 56 |
> |
| 57 |
> -- |
| 58 |
> Peter. |
| 59 |
> |
| 60 |
> |
| 61 |
> |
Archives