| 1 |
On Friday 30 July 2004 03:41, Brian Harring wrote: |
| 2 |
> Unless someone can give me a valid reason why this functionality must |
| 3 |
> be bundled, then no, that isn't the problem- the problem is that they |
| 4 |
> -are- bundled with portage. |
| 5 |
|
| 6 |
Not from me. |
| 7 |
|
| 8 |
> These utilites are specific to our tree, and should be correct for the |
| 9 |
> tree *at that moment*. I really am not fond of the notion that, while |
| 10 |
> the ebuild may be correct, the portage version's bundled utilities are |
| 11 |
> broke so the ebuild misbehaves. |
| 12 |
|
| 13 |
This is the only valid reason I've heard. However, what about the other way? |
| 14 |
An ebuild is installed and goes to be unmerged but the support functions used |
| 15 |
during prerm have changed slightly causing it to break. I realize this is an |
| 16 |
issue anyway, but one that hasn't cropped up yet. |
| 17 |
|
| 18 |
Code-wise, there are two possibilities. One is to bundle the support functions |
| 19 |
into the saved environment and the other is to not. Not bundling allows the |
| 20 |
possibility above. Bundling leads to the possibility that an ebuild is |
| 21 |
installed with a broken function (that is only used during prerm) that has no |
| 22 |
way of being fixed. |
| 23 |
|
| 24 |
The fix? I'd say to make sure the behaviour of every function is well |
| 25 |
documented and ensuring that the behaviour doesn't change in general. I |
| 26 |
presonally think that any extension would normally warrant a new function so |
| 27 |
that ebuilds know exactly what they're getting. However, even if that's not |
| 28 |
adopted, having the documentation means that any extension can be better |
| 29 |
audited. |
| 30 |
|
| 31 |
Regards, |
| 32 |
Jason Stubbs |
| 33 |
|
| 34 |
-- |
| 35 |
gentoo-dev@g.o mailing list |
Archives