| 1 |
1.3.2006, 13:09:55, Paul de Vrieze wrote: |
| 2 |
|
| 3 |
> On Tuesday 28 February 2006 21:20, Ciaran McCreesh wrote: |
| 4 |
|
| 5 |
>> | > if [ "${IS_UPGRADE}" = "1" ] ; then |
| 6 |
>> | > einfo "Removing old version ${REMOVE_PKG}" |
| 7 |
>> | > |
| 8 |
>> | > emerge -C "${REMOVE_PKG}" |
| 9 |
>> | > fi |
| 10 |
|
| 11 |
> This code (or an equivalent kludge/hack) does however allow features that are |
| 12 |
> of great value to our users. While I agree that such hacks should be avoided |
| 13 |
> if possible, I think in this case it is not. As such the appropriate response |
| 14 |
> is to isolate the hack in a central place, where it is clear to be seen and |
| 15 |
> can easilly be fixed. This allows the quality of the hack to be ensured, |
| 16 |
> relieving many webapps from doing hacks themselves. |
| 17 |
|
| 18 |
> While this hack is being used, some effort should be put into |
| 19 |
> constructively creating a proper solution for the problems that were |
| 20 |
> hacked around. Saying "this is not allowed because of X policy" is not |
| 21 |
> helpful as the costs of disallowing it greatly outweigh the costs of |
| 22 |
> overlooking it in a controlled manner. |
| 23 |
|
| 24 |
Well yeah, but the problem here is that portage doesn't allow such stuff to |
| 25 |
be used safely (locking issues, race conditions). And yeah, it's kinda |
| 26 |
lacking sort of feature that would have its use in a couple of places. |
| 27 |
|
| 28 |
-- |
| 29 |
|
| 30 |
jakub |
Archives