| 1 |
Sebastian Günther <samson@××××××××××××××××.de> writes: |
| 2 |
|
| 3 |
> * Harry Putnam (reader@×××××××.com) [12.06.09 16:41]: |
| 4 |
>> |
| 5 |
>> There is a patch offered but still one would think using standard |
| 6 |
>> emerge on a package that is outside the `~' daredevil stage and is not |
| 7 |
>> masked, it should `just work' [tm]. |
| 8 |
>> |
| 9 |
>> |
| 10 |
> |
| 11 |
> When I read the bug rightfully, procmail did not build with glibc |
| 12 |
> 2.10.1, which is *not* stable yet, especially because of a lot packages |
| 13 |
> which don't build cleanly with it at the moment. |
| 14 |
> |
| 15 |
> So if you'd use the stable glibc it would build fine. There is no need |
| 16 |
> to mark procmail in any way. ~x86 should be able to apply patches on |
| 17 |
> their own, or wait until the patch arrives in tree. |
| 18 |
|
| 19 |
Probably should use only stable but never have in over 5 yrs. |
| 20 |
Probably much to the dismay of this list. |
| 21 |
|
| 22 |
But even then, when a package is known in advance NOT to install with |
| 23 |
current ~x86 tools, seems there would be some way to let user know |
| 24 |
that. |
| 25 |
|
| 26 |
Since you've said it is because of glibc... and this is a known bug |
| 27 |
seems there might be a way to flag or mark procmail as incompatible |
| 28 |
with it. |
| 29 |
|
| 30 |
Maybe that would be way to hard to keep up with? |
Archives