Markos Chandras posted on Sat, 14 Aug 2010 20:00:40 +0300 as excerpted:
> Cause I don't like users to compile the same damn package over and over.
> -r1 for docs on ${PF}, -r2 for CFLGAS, -r3 for LDFLAGS, -r4 for ... Is
> that a good reason or not? It is not like I introduce huge patches with
> bugfixes etc. My fixes are QA fixes not *serious* bugfixes anyway.
> Furthermore the QA fixes I do ( CC,CFLAGS,LDFLAGS ) are easily spotted
> and there isn't much for users to test anyway. Either you respect the
> bloody flags or not. I don't do blindly commits. I try to test the
> packages in multiple chroots anyway.
User perspective here...
For LDFLAGS, given the new --as-needed default, I'd prefer the rev-bump.
Yes, it requires a rebuild, but the rebuilds will occur as the bugs are
fixed so it's a few at a time for people who keep reasonably updated
(every month or more frequently). The alternative is triggering a several-
hundred-package rebuild when some base library package updates, because
all those LDFLAGS respecting changes weren't rev-bumped and the user's
installed set is still ignoring them, and thus --as-needed.
Better the few at a time, even if some of them end up being bumped and
built twice as a result, than the multiple hundred at once.
So I'm not going to get into who's right or wrong vs. current policy, but
that's my perspective as a user. For LDFLAGS respecting changes at least,
please do the rev-bumps, as the cost of failing to do so, thus triggering
a mass update when a base lib changes, far exceeds that of dealing with
them on a trickle-in basis, even if a few do end up updated twice as a
result.
Thanks. =:^)
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
