HEADS UP: Merge of binutils 2.17

Doug Barton dougb at FreeBSD.org
Fri Jan 7 23:37:31 UTC 2011


On 01/07/2011 13:54, Ade Lovett wrote:
>
> On Jan 07, 2011, at 15:41 , Doug Barton wrote:
>> On 01/07/2011 13:29, Dimitry Andric wrote:
>>>
>>> Yes, I submitted an exp-run request Nov 15, 2010:
>>> http://www.freebsd.org/cgi/query-pr.cgi?pr=152268 Unfortunately,
>>> there has been little or no interest.
>>
>> Fair enough, that sounds to me like portmgr is volunteering to
>> clean up the mess then.
>
> Most likely it's low priority given all the other exp-runs that
> affect 7.x/8.x, tweaking things for an 6.x-EOL-tagged tree, and a
> bunch of other infrastructure stuff.  Not to mention the impending 7-
> and 8- RELEASEs.

That may very well be the case, but if so then it's incumbent on portmgr 
to communicate that. If you check the audit trail you will find that 
they did not.

> Then of course there's the issue (which is certainly getting better)
> of finding a point in time along the -CURRENT path where the tree is
> stable (sic) enough to get through a full ports run (which is one of
> the bigger internal stress tests we have of the system).

IMO this is a total red herring, and has been for several years now. I 
run -current every day on my real-work system, and barring the 
occasional hiccup it's been buildable nearly every time I've tried.

The way I would approach the problem of building packages for -current 
is to pick a day to update the src tree, then do the following:

1. make buildworld && make kernel && reboot &&
2. make installworld && reboot &&
3. update ports tree &&
4. start building ports

That can all be automated, and at the point where any of it fails the 
system barks loudly and stops trying to proceed. This would of course 
require a human to be involved once a week or so with running 
mergemaster, and maybe the odd cleanup here or there, but most times 
that doesn't even have to happen in band. I suggest Wednesday as "the 
day" to update the source since there is usually a lot of activity on 
the weekend, and if something is broken on Wednesday it gives people a 
chance to respond during working hours.

The great thing about this is that if it fails, no harm no foul. Having 
some packages, even a week or so out of date is much better than what we 
have now.

Of course, there are other things that would go along with this ... 
finding and tagging the very few packages that actually deeply care 
about system internals being first on the "off the top of my head" list. 
But the current system of "don't do anything" just isn't cutting it.

> IMO, the best approach would be to make sure it does the right thing
> with 'make universe' (twice, naturally, the second time being when
> all traces of the previous binutils has been purged from the building
> system).  Once that's done, commit (please bump __FreeBSD_version as
> part of this, in case ports OSVERSION hacks are eventually needed),
> and then give the exp-run a whirl -- with all of the above, this
> should be nicely after 7.4/8.2

If portmgr is unwilling/unable to do the exp-run before dim is ready to 
commit, then I'd say yes, that all sounds fine; especially bumping 
__FreeBSD_version.


hth,

Doug

-- 

	Nothin' ever doesn't change, but nothin' changes much.
			-- OK Go

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/



More information about the freebsd-current mailing list