| 1 |
On 08/14/2010 02:35 PM, Duncan wrote: |
| 2 |
> User perspective here... |
| 3 |
> |
| 4 |
> For LDFLAGS, given the new --as-needed default, I'd prefer the rev-bump. |
| 5 |
> Yes, it requires a rebuild, but the rebuilds will occur as the bugs are |
| 6 |
> fixed so it's a few at a time for people who keep reasonably updated |
| 7 |
> (every month or more frequently). The alternative is triggering a several- |
| 8 |
> hundred-package rebuild when some base library package updates, because |
| 9 |
> all those LDFLAGS respecting changes weren't rev-bumped and the user's |
| 10 |
> installed set is still ignoring them, and thus --as-needed. |
| 11 |
|
| 12 |
Interesting - I was looking at it in the opposite way. |
| 13 |
|
| 14 |
Not having as-needed means that I /might/ have to rebuild that one |
| 15 |
package unnecessarily at some point in the future - if it isn't upgraded |
| 16 |
first for some other reason. |
| 17 |
|
| 18 |
Rev-bumping the build means that I /will/ have to rebuild that one |
| 19 |
package for certain - right now. |
| 20 |
|
| 21 |
I think we can all at least agree that this is a gray area as far as the |
| 22 |
INTENT of the (apparently unwritten) policy goes. |
| 23 |
|
| 24 |
I would like to echo Markos's comment that having policies written down, |
| 25 |
if only to point stubborn maintainers to them, would be helpful. The |
| 26 |
other reason to have them written is so that they go through some kind |
| 27 |
of review, and there is some way of challenging them if they no longer |
| 28 |
make sense. |
| 29 |
|
| 30 |
In any case, I think we're making a pretty big deal about a pretty small |
| 31 |
issue - we can probably all afford to think about this a little more and |
| 32 |
move on... |
| 33 |
|
| 34 |
Rich |
Archives