| 1 |
Ciaran McCreesh schrieb: |
| 2 |
> On Sun, 11 Mar 2012 17:18:45 +0100 |
| 3 |
> Chí-Thanh Christopher Nguyễn <chithanh@g.o> wrote: |
| 4 |
>> Assume a new version 13.37 of your package manager drops EAPI=1 |
| 5 |
>> support. So package-manager-13.37.ebuild checks in pkg_pretend() if |
| 6 |
>> any EAPI=1 package is installed on the system. If yes, then it |
| 7 |
>> aborts, telling the user to get rid of the package first. |
| 8 |
> Oh, now I get it. There are two issues there... |
| 9 |
> |
| 10 |
> First, doing that is going to screw things up for users who have two |
| 11 |
> package managers installed, unless you make every package mangler's |
| 12 |
> package aware of every package mangler. |
| 13 |
|
| 14 |
As long as the package managers are installed through ebuilds, they |
| 15 |
should observe each other's pkg_pretend() |
| 16 |
|
| 17 |
> Second, there's not a way of getting the information you need to figure |
| 18 |
> that out using current EAPIs. |
| 19 |
|
| 20 |
That I suspected, that's why I asked about feasibility. |
| 21 |
"grep 1 $(portageq vdb_path)/*/*/EAPI && die" might work for portage and |
| 22 |
its current VDB layout. |
| 23 |
One problem that remains with this approach is what happens if an EAPI=1 |
| 24 |
package is in the list of packages to be merged along with the new |
| 25 |
package manager. |
| 26 |
|
| 27 |
> It's also not really worth it at the moment. There aren't any major |
| 28 |
> architectural changes between EAPIs just now, so removing support for |
| 29 |
> an EAPI won't allow any majorly nasty code to be removed from a package |
| 30 |
> manager. It might be worth revisiting this if we ever switch to EAPIs |
| 31 |
> that allow us to kill off VDB, for example. |
| 32 |
|
| 33 |
Yes, tommy already told me on IRC that there is no incentive for package |
| 34 |
managers to drop EAPI support at this time. |
| 35 |
|
| 36 |
|
| 37 |
Best regards, |
| 38 |
Chí-Thanh Christopher Nguyễn |
Archives