| 1 |
On Wed, 14 Aug 2013 11:50:56 -0400 |
| 2 |
"Anthony G. Basile" <blueness@g.o> wrote: |
| 3 |
> On 08/14/2013 11:41 AM, Patrick Lauer wrote: |
| 4 |
> > On 08/14/2013 10:17 PM, Ciaran McCreesh wrote: |
| 5 |
> >> On Wed, 14 Aug 2013 17:07:32 +0400 |
| 6 |
> >> Sergey Popov <pinkbyte@g.o> wrote: |
| 7 |
> >>> I am all for the standarts, but as we did not brought sets to PMS |
| 8 |
> >>> yet(when we updated it for EAPI changes), my question is: 'why?'. |
| 9 |
> >>> It is one of the long-standing feature of quite experimental |
| 10 |
> >>> 2.2_alpha branch, that should finally come to release(Thanks to |
| 11 |
> >>> portage team, by the way :-)). |
| 12 |
> >>> |
| 13 |
> >>> Why it was not added as a part of the PMS? Some implementation |
| 14 |
> >>> flaws? Or maybe, architecture problems? |
| 15 |
> >> Because the Portage format involves executing arbitrary Python code |
| 16 |
> >> that can depend in arbitrary ways upon undocumented Portage |
| 17 |
> >> internals that can change between versions. |
| 18 |
> >> |
| 19 |
> > You keep repeating that. |
| 20 |
> > |
| 21 |
> > That doesn't make it more true. |
| 22 |
> > |
| 23 |
> |
| 24 |
> Even if it were true, this does not stop pms from providing an |
| 25 |
> abstraction layer which provides the needed support despite the |
| 26 |
> details of the underlying implementation. The argument that |
| 27 |
> implementation details limit such possibilities is spurious and |
| 28 |
> should be ignored. |
| 29 |
|
| 30 |
Why would we design a spec around "arbitrary list of class names that |
| 31 |
happen to be present in some particular version of Portage"? |
| 32 |
|
| 33 |
-- |
| 34 |
Ciaran McCreesh |
Archives