| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
Hi everyone, |
| 5 |
|
| 6 |
As many of you probably know already, bug 46223 [1] prevents the |
| 7 |
proper uninstallation of a package when one or more of the eclasses |
| 8 |
that it inherits are missing from the live portage tree. |
| 9 |
|
| 10 |
There are essentially two ways to solve this problem: |
| 11 |
|
| 12 |
Approach #1: Reuse the saved environment which contains a mixture of |
| 13 |
eclasses and parts of the package manager (such as portage's |
| 14 |
ebuild.sh) that performed the installation. |
| 15 |
|
| 16 |
Approach #2: Save copies of the raw eclasses and use them, together |
| 17 |
with the saved ebuild, to recreate the environment. |
| 18 |
|
| 19 |
A major advantage of approach #1 is that it can potentially provide |
| 20 |
complete restoration of the install-time environment. The major |
| 21 |
disadvantage is that the saved environment needs to be purified so |
| 22 |
that parts of the package manager that did the install do not |
| 23 |
interfere with the package manager that does the uninstall. The |
| 24 |
purification process could potentially be complex or error prone, |
| 25 |
making it difficult to maintain or unreliable. |
| 26 |
|
| 27 |
Simplicity is the major advantage approach #2. The eclasses that |
| 28 |
are used by a package could be stored in eclasses.tbz2 (much like |
| 29 |
enviroment.bz2 is currently stored for each installed package), and |
| 30 |
the environment could be recreated from scratch by using the ebuild |
| 31 |
and eclasses in the normal inherit process. This wouldn't |
| 32 |
necessarily allow access to the complete build-time or install-time |
| 33 |
environment, but that feature is not currently available anyway. If |
| 34 |
we save the raw eclasses for each installed package, we can easily |
| 35 |
gain the ability to remove eclasses from the portage tree and make |
| 36 |
incompatible api changes when necessary, without the complexity of |
| 37 |
environment purification. |
| 38 |
|
| 39 |
What do people think about these two approaches? Personally, I |
| 40 |
would prefer approach #2 for the sake of simplicity and |
| 41 |
maintainability. The sooner that we start storing eclasses.tbz2 for |
| 42 |
each installed package, the sooner that we will be able to have more |
| 43 |
freedom with the eclasses in the live portage tree. |
| 44 |
|
| 45 |
Zac |
| 46 |
|
| 47 |
[1] http://bugs.gentoo.org/show_bug.cgi?id=46223 |
| 48 |
|
| 49 |
-----BEGIN PGP SIGNATURE----- |
| 50 |
Version: GnuPG v1.4.5 (GNU/Linux) |
| 51 |
|
| 52 |
iD8DBQFFTF58/ejvha5XGaMRApOeAJ9CncD89mRUy/mhyVZnhFjmazjYYACfYhdy |
| 53 |
4qLqBySCLvAyuNm58bqXZnY= |
| 54 |
=Ailg |
| 55 |
-----END PGP SIGNATURE----- |
| 56 |
-- |
| 57 |
gentoo-dev@g.o mailing list |
Archives