| 1 |
On Mon, 30 Mar 2015 13:04:47 +0000 (UTC), Holger Hoffstätte wrote: |
| 2 |
|
| 3 |
> > The news item also showed how to make it a global choice, avoiding the |
| 4 |
> > need to multiple per-package directories. |
| 5 |
> |
| 6 |
> I'm not sure that's a solution to the problem at all (which is why I |
| 7 |
> didn't do it on my machines either). Apart from always wasting much more |
| 8 |
> work & resources than necessary for no good reason it doesn't answer the |
| 9 |
> question what happens as soon as I want to build a package that is |
| 10 |
> 64-bit-only - in which case you'd end up in the same situation we have |
| 11 |
> now, just mirrored. |
| 12 |
|
| 13 |
Yes, the only question is would it be a better or worse situation. From a |
| 14 |
pragmatic point of view it would be better, since the only inconvenience |
| 15 |
would be in extra builds, nothing would stop working in the meantime and |
| 16 |
you are far less likely to get blockers. |
| 17 |
|
| 18 |
Neither solution is ideal, but the change from the old binary packages had |
| 19 |
to be made at some point. At least we will now be spared the messages |
| 20 |
from revdep-rebuild and perl-cleaner about binary packages that won't |
| 21 |
change no matter how many time we reinstall them. |
| 22 |
|
| 23 |
|
| 24 |
-- |
| 25 |
Neil Bothwick |
| 26 |
|
| 27 |
Processor: (n.) a device for converting sense to nonsense at the speed |
| 28 |
of electricity, or (rarely) the reverse. |
Archives