Gentoo Archives: gentoo-dev

From: Brian Harring <ferringb@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Moving functionality out of portage and into the tree
Date: Fri, 30 Jul 2004 00:54:11
Message-Id: CF24DB52-E1C2-11D8-BB36-000A95C08860@gentoo.org
In Reply to: Re: [gentoo-dev] Moving functionality out of portage and into the tree by Jason Stubbs
1 -----BEGIN PGP SIGNED MESSAGE-----
2 Hash: SHA1
3
4 On Jul 29, 2004, at 6:19 PM, Jason Stubbs wrote:
5 >> These utilites are specific to our tree, and should be correct for the
6 >> tree *at that moment*. I really am not fond of the notion that, while
7 >> the ebuild may be correct, the portage version's bundled utilities are
8 >> broke so the ebuild misbehaves.
9 >
10 > This is the only valid reason I've heard. However, what about the
11 > other way?
12 > An ebuild is installed and goes to be unmerged but the support
13 > functions used
14 > during prerm have changed slightly causing it to break. I realize this
15 > is an
16 > issue anyway, but one that hasn't cropped up yet.
17
18 Script arguments (so far) have always maintained backwards
19 compatibility- regardless of the location the script is stored in (or
20 where it comes from), the maintaining backwards compatibility of
21 arguments is an issue.
22
23 >
24 > Code-wise, there are two possibilities. One is to bundle the support
25 > functions
26 > into the saved environment and the other is to not. Not bundling
27 > allows the
28 > possibility above. Bundling leads to the possibility that an ebuild is
29 > installed with a broken function (that is only used during prerm) that
30 > has no
31 > way of being fixed.
32
33 The issues you're raising are more so related to my env save/restore
34 code in bug #56408, then this thread.
35 Currently, portage re-sources the ebuild (and eclasses) at every step-
36 the env is reloaded, but all functions are overwritten (along with
37 small # of vars). A borked function saved in the env is overwritten by
38 ebuild.sh, and would be even if we split off an ebuild-base.eclass .
39 Course as you pointed out, the converse of this is that a borked
40 function in the current portage version would override the correct
41 version in the saved env.
42
43 > The fix? I'd say to make sure the behaviour of every function is well
44 > documented and ensuring that the behaviour doesn't change in general.
45
46 Changes in function behaviour would be possible if the env handling
47 I've setup in bug #56408 was in portage- by saving the function w/ the
48 ebuild, you're basically taking a snapshot of everything at that point.
49 As long as the tree has been updated prior, changes to functions (such
50 as the use_enable/use_with change in .51) wouldn't have to worry about
51 screwing up prerm's of installed ebuilds.
52 That said, it's a separate issue from splitting scripts/functions out :)
53
54 > I presonally think that any extension would normally warrant a new
55 > function so
56 > that ebuilds know exactly what they're getting. However, even if
57 > that's not
58 > adopted, having the documentation means that any extension can be
59 > better
60 > audited.
61 Current portage, yeah, changes to ebuild.sh functions that ebuild's
62 directly call should be limited to bug fixes- *never* changing default
63 behaviour.
64 Basically the issues you raised above is why I did the env handling
65 code in bug #56408, that and ebuilds expecting
66 export'd/readonly/declare -i'd variables to retain their original
67 attributes across ebuild phases.
68
69 For commentary above, I've assumed you're talking about bash
70 functionality- if you're referring to the scripts in bin/*, we've yet
71 to bundle those w/ an installed ebuild. Possible I spose, although
72 again, that falls under another thread/bug; it would be an extension of
73 portage's env snapshot code, and wouldn't care about where it got the
74 scripts from, just as long as it could find them :)
75 ~brian
76 -----BEGIN PGP SIGNATURE-----
77 Version: GnuPG v1.2.4 (Darwin)
78
79 iD8DBQFBCZvxvdBxRoA3VU0RAmbzAKDQII3D5qhv3CONhvh/ExSbjsiJBwCglrpk
80 hNZgSaUIO3h18bb4prnqCWY=
81 =YwaB
82 -----END PGP SIGNATURE-----
83
84
85 --
86 gentoo-dev@g.o mailing list

Replies