| 1 |
Andres Loeh wrote: |
| 2 |
> The reason is (please correct me if I'm wrong) that, as far as I |
| 3 |
> can see, when an ebuild is installed on a user's machine, the ebuild |
| 4 |
> is saved, but not the eclasses it depends on. Should the user later |
| 5 |
> decide that the package should be removed from his system (or |
| 6 |
> updated), then the pkg_prerm and pkg_postrm functions from the *old* |
| 7 |
> ebuild are executed in conjunction with the *current* versions of |
| 8 |
> the eclasses it depends on. And the older an ebuild is, the more |
| 9 |
> likely it gets that the eclass has evolved beyond compatibility in |
| 10 |
> the meantime. |
| 11 |
|
| 12 |
I believe the current CVS version of portage already fixes this properly |
| 13 |
by saving the eclass along with the ebuild. If not, then it probably |
| 14 |
will at some point in the near future... at least, I remember ferringb |
| 15 |
talking about this. |
| 16 |
|
| 17 |
Only slightly on-topic, but I think saving eclasses and not killing |
| 18 |
space needlessly would be an interesting effort. almost every installed |
| 19 |
ebuild will have a full copy of eutils and flag-o-matic in /var/db/. ^^; |
| 20 |
|
| 21 |
perhaps a versioning system of some sort would be useful there |
| 22 |
instead... so that only one copy of any versioned eclass would be in |
| 23 |
/var/db/ at any one time. but as for using versioned eclasses in |
| 24 |
ebuilds... i can see that becoming pretty ugly pretty quickly. :/ |
| 25 |
|
| 26 |
...also, i like debugging eclasses using binary packages, so i would |
| 27 |
hope that a solution where eclasses are stored in /var/db/ would also |
| 28 |
have an option for using the current in-tree eclass. I'm just sillie |
| 29 |
like that. ;p |
| 30 |
|
| 31 |
|
| 32 |
Travis Tilley |
| 33 |
|
| 34 |
-- |
| 35 |
gentoo-dev@g.o mailing list |
Archives