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 |