Gentoo Archives: gentoo-dev

From: Zac Medico <zmedico@g.o>
To: gentoo-dev@g.o
Subject: [gentoo-dev] RFC: persistence of eclasses for installed packages
Date: Sat, 04 Nov 2006 09:45:34
2 Hash: SHA1
4 Hi everyone,
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.
10 There are essentially two ways to solve this problem:
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 that performed the installation.
16 Approach #2: Save copies of the raw eclasses and use them, together
17 with the saved ebuild, to recreate the environment.
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.
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.
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.
45 Zac
47 [1]
50 Version: GnuPG v1.4.5 (GNU/Linux)
52 iD8DBQFFTF58/ejvha5XGaMRApOeAJ9CncD89mRUy/mhyVZnhFjmazjYYACfYhdy
53 4qLqBySCLvAyuNm58bqXZnY=
54 =Ailg
55 -----END PGP SIGNATURE-----
56 --
57 gentoo-dev@g.o mailing list


Subject Author
Re: [gentoo-dev] RFC: persistence of eclasses for installed packages "Petteri Räty" <betelgeuse@g.o>
Re: [gentoo-dev] RFC: persistence of eclasses for installed packages Brian Harring <ferringb@×××××.com>