Gentoo Archives: gentoo-dev

From: Dale <rdalek1967@×××××.com>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild
Date: Sat, 14 Aug 2010 22:01:10
Message-Id: 4C671200.7040603@gmail.com
In Reply to: Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild by Richard Freeman
1 Richard Freeman wrote:
2 > On 08/14/2010 02:35 PM, Duncan wrote:
3 >> User perspective here...
4 >>
5 >> For LDFLAGS, given the new --as-needed default, I'd prefer the rev-bump.
6 >> Yes, it requires a rebuild, but the rebuilds will occur as the bugs are
7 >> fixed so it's a few at a time for people who keep reasonably updated
8 >> (every month or more frequently). The alternative is triggering a
9 >> several-
10 >> hundred-package rebuild when some base library package updates, because
11 >> all those LDFLAGS respecting changes weren't rev-bumped and the user's
12 >> installed set is still ignoring them, and thus --as-needed.
13 >
14 > Interesting - I was looking at it in the opposite way.
15 >
16 > Not having as-needed means that I /might/ have to rebuild that one
17 > package unnecessarily at some point in the future - if it isn't
18 > upgraded first for some other reason.
19 >
20 > Rev-bumping the build means that I /will/ have to rebuild that one
21 > package for certain - right now.
22 >
23 > I think we can all at least agree that this is a gray area as far as
24 > the INTENT of the (apparently unwritten) policy goes.
25 >
26 > I would like to echo Markos's comment that having policies written
27 > down, if only to point stubborn maintainers to them, would be
28 > helpful. The other reason to have them written is so that they go
29 > through some kind of review, and there is some way of challenging them
30 > if they no longer make sense.
31 >
32 > In any case, I think we're making a pretty big deal about a pretty
33 > small issue - we can probably all afford to think about this a little
34 > more and move on...
35 >
36 > Rich
37 >
38 >
39
40
41 I'm with Duncan as well. I update pretty regular, usually daily, just
42 because I want to update a few packages at a time. If I do a truly HUGE
43 update, what is it that broke what? If I do 3 to 10 packages and
44 something breaks, I can go look at those 3 to 10 packages for either a
45 version mismatch or just a plain old broken package. If I have to
46 update everything at once, where does one even start to look? I have
47 almost a thousand packages here and I would hate to have to go look for
48 a needle in a haystack. That's a large haystack to go looking in.
49
50 I might also mention that I see rebuilds from time to time where it
51 looks like nothing has changed. I always let them rebuild anyway
52 because I know there is something different under the hood that I don't
53 see. Open Office is one that I dread tho. lol Even tho it would mean
54 a gradual system rebuild, I'd say that I'm for it. As they get changed,
55 bump them up a notch and let them get rebuilt.
56
57 Back to my hole now.
58
59 Dale
60
61 :-) :-)