| 1 |
Just curious whether there is any value at continuing to offer a libperl |
| 2 |
ebuild (which creates libperl.so for you) and then having perl |
| 3 |
statically built against an internally generated libperl.a (substitute |
| 4 |
your platforms appropriate names porters :) Traditionally we offered |
| 5 |
both libperl's, and perl itself gets statically built against the static |
| 6 |
library, but I'm just curious if anyone has a use for this still? |
| 7 |
Maintaining the two isn't usually a problem, but it can lead to end-user |
| 8 |
problems if one is upgraded and not the other (say during a security |
| 9 |
update), as well as patch maintenance, etc., versus having a perl that |
| 10 |
will work even when everything dynamic is dead. Just looking for |
| 11 |
opinions, upstream's on the verge of releasing 5.8.8 so I figured now |
| 12 |
was as good a time as any to gather opinions :) |
| 13 |
|
| 14 |
~mcummings |
Archives