| 1 |
28.2.2006, 18:38:10, Ciaran McCreesh wrote: |
| 2 |
|
| 3 |
|
| 4 |
> Sheesh, you'll probably claim that this isn't broken next too: |
| 5 |
|
| 6 |
> if [ "${IS_UPGRADE}" = "1" ] ; then |
| 7 |
> einfo "Removing old version ${REMOVE_PKG}" |
| 8 |
|
| 9 |
> emerge -C "${REMOVE_PKG}" |
| 10 |
> fi |
| 11 |
|
| 12 |
No, I won't claim that... I'd rather love to know why didn't you point out |
| 13 |
to an obvious eclass flaw about 30 emails and many hours ago, saving us from |
| 14 |
all the eclass formating, slotting and ewarn blurb. The above needs to be |
| 15 |
fixed, period. |
| 16 |
|
| 17 |
To return to the original topic - focus your QA efforts on real issues. Same |
| 18 |
goes for that non-interactivity stuff. QA that serves no other purpose than |
| 19 |
inventing problems to enforce an inevitably hackish solution (there's no |
| 20 |
good one because the needed tools are not available) is not useful at all. |
| 21 |
There's nothing useful in inventing policies that create more problems than |
| 22 |
they solve and that are forcing shitty bash code into the tree to work |
| 23 |
around missing features. |
| 24 |
|
| 25 |
Portage is a tool to install and manage packages, and serves no good purpose |
| 26 |
on its own. Crippling installed packages and their available features for |
| 27 |
the sole purpose of having nice ebuild tree with clean bash code is not what |
| 28 |
QA is for. Improving the whole process is fine and welcome, as long as it |
| 29 |
doesn't unnecessarily interfere with the desired outcome. Users need to |
| 30 |
install some software they want to use and need its features, portage and |
| 31 |
ebuids are only the means to do that, not a holy cow. |
| 32 |
|
| 33 |
|
| 34 |
-- |
| 35 |
|
| 36 |
jakub |
Archives