| 1 |
On Fri, Aug 10, 2012 at 4:21 PM, Jeroen Roovers <jer@g.o> wrote: |
| 2 |
> On Fri, 10 Aug 2012 14:03:23 +0200 |
| 3 |
> Gilles Dartiguelongue <eva@g.o> wrote: |
| 4 |
> |
| 5 |
>> Since you are proposing this, a side question is: |
| 6 |
>> Why should we write SRC_URI in ebuilds if that info is now available |
| 7 |
>> in metadata.xml ? (granted that we might still want to keep |
| 8 |
>> over-riding this information in ebuilds) |
| 9 |
> |
| 10 |
> 1) The information in metadata.xml is inaccurate, it's a hint. When it |
| 11 |
> fails, nothing of value is lost since the ebuild (supposedly) has |
| 12 |
> what you want. |
| 13 |
> 2) SRC_URI is precise. |
| 14 |
> 3) SRC_URI can change over time, and across versions (even with all the |
| 15 |
> variables in place). |
| 16 |
> 4) Backward compatibility. |
| 17 |
> 5) The inversion of your question: Why should we start handling SRC_URI |
| 18 |
> outside ebuilds and eclasses? Or, how would that be practical, |
| 19 |
> advantageous, an improvement on the current situation. |
| 20 |
|
| 21 |
Right, our proposal is not here to replace SRC_URI, it's here to fix |
| 22 |
the cases where SRC_URI can't be sanely used to guess new upstream |
| 23 |
versions (strange mangling rules, unbrowsable directories, etc...). |
| 24 |
|
| 25 |
-- |
| 26 |
Corentin Chary |
| 27 |
http://xf.iksaif.net |
Archives