Archives
Archives
| From: | Ciaran McCreesh <ciaran.mccreesh@××××××××××.com> | ||
|---|---|---|---|
| To: | gentoo-dev@l.g.o | ||
| Subject: | Re: [gentoo-dev] Re: RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem | ||
| Date: | Tue, 20 Sep 2011 10:46:18 | ||
| Message-Id: | 20110920114013.5c2b69dc@googlemail.com | ||
| In Reply to: | Re: [gentoo-dev] Re: RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem by Brian Harring |
||
| 1 | On Tue, 20 Sep 2011 03:28:48 -0700 |
| 2 | Brian Harring <ferringb@×××××.com> wrote: |
| 3 | > Paludis wise, it's eapi2 indirictely due to boost and eselect. |
| 4 | > Looking at the eapi depgraph for that, doesn't look particularly |
| 5 | > viable for upgrading from a EAPI<2 manager for paludis. I'll leave |
| 6 | > it to Ciaran to comment on the feasability of a static rescue |
| 7 | > binary (or extremely simplified upgrade pathway). |
| 8 | |
| 9 | boost's just for Python bindings, which are optional. The eselect |
| 10 | dependency is hard, and can't easily be made optional, so ideally |
| 11 | eselect should stick with older EAPIs. |
| 12 | |
| 13 | Maybe we should stick something in metadata.xml... |
| 14 | |
| 15 | -- |
| 16 | Ciaran McCreesh |
| File name | MIME type |
|---|---|
| signature.asc | application/pgp-signature |
| Subject | Author |
|---|---|
| Re: [gentoo-dev] Re: RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem | Brian Harring <ferringb@×××××.com> |
| Re: [gentoo-dev] Re: RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem | Ulrich Mueller <ulm@g.o> |