Page MenuHomeFreeBSD

Change procedure in UPDATING to use etcupdate(8) over mergemaster(8)
AcceptedPublic

Authored by driesm.michiels_gmail.com on Jan 9 2021, 1:57 PM.

Details

Reviewers
ngie
bcr
imp
debdrup
ceri
Group Reviewers
docs
Summary

This changes the procedure in UPDATING to use etcupdate over megemaster. This follows the recommandations in the handbook diff at D27848.
PR: 252417

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint OK
Unit
No Unit Test Coverage
Build Status
Buildable 38810
Build 35699: arc lint + arc unit

Event Timeline

Could you please add PR: 252417 to the commit message?

UPDATING
2403

It never hurts to do it all the time.

This advice can actually break a system if the new etcupdate relies on behavior/code from the newly built world.

Please remove this comment or add similar advice to the original advice, noting the potential pitfall of using etcupdate(8), which can be incompatible with the old installed world.

2403

This was also the case for mergemaster too. Oof... that was bad advice.

Thanks for the review! I don't have a bit but I have updated the description with the PR number.

UPDATING
2403

So the comment that was there before is also applicable for worlds after 20130425 and 20130430? As the message only hints for the pitfall if we are updating from before these revisions (the way I interpret it, possibly incorrect though). Or is it a possible pitfall in general? If so I would just drop the specific revisions mentioned there as its confusing.

My eyeballs tell me these changes are good, but I've not 'play tested' them in anger to be sure.

UPDATING
2408

This change is independent, but imho, not important enough to do as a separate commit.

This revision is now accepted and ready to land.Mar 17 2021, 8:21 PM

Hi @debdrup, as you landed my review for updating the handbook to reference etcupdate, do you mind taking this one too? Thanks

grahamperrin_gmail.com added inline comments.
UPDATING
2315

Move up, to be inline.

2316

Remove white space.

2353

Move up, to be inline.

2354

Remove white space.

2358

I know that deleting old libraries can cause breakage (if performed carelessly).

Is there also risk of breakage for delete-oldwithout attention to libraries?

I routinely:

make -DBATCH_DELETE_OLD_FILES delete-old

– and never encountered breakage. Touch wood.

2383

Take this opportunity to renumber 3, 4, 5, 6, 8 and 9, and the referring points?

(There is no footnote 2 or 7.)

Then – order – begin the points, and their footnotes, at 1 instead of 7.

2429

Add white space between this line and the subheading that follows.

2440

1998–2021

UPDATING
2440

I've not been the majority contributor since 2009.

UPDATING
2283

if there is no EFI system partition

driesm.michiels_gmail.com marked an inline comment as done.

No real change intended rebased to master.

This revision now requires review to proceed.Apr 22 2021, 6:46 PM

In general your comments are valid and will open different reviews for some of them. But I'd like to keep this one just simple to change the mergemaster commands to etcupdate.

UPDATING
2315

It is intended like this so that it is not associated with make installkernel, it is seen as a seperate step between installkernel and reboot to single user mode.

2358

I'm trying to focus this review on mergemsater => Etcupdate. I've already folded in one unrelated change. I hope you understand.

2383

I'm trying to focus this review on mergemsater => Etcupdate. I've already folded in one unrelated change. I hope you understand.

… keep this one just simple to change the mergemaster commands to etcupdate.

Understood and agreed; https://reviews.freebsd.org/D29934 noted with thanks.

Hi all, could this regain some traction?
The conflicting information between the handbook and the notes in UPDATING is confusing a few people on the forums etc.

Change looks good, I think, but is there any reason not to renumber those "footnotes" at the same time so that they are vaguely in order and 2 and 7 aren't missing for no good reason?

In D28062#690276, @ceri wrote:

Change looks good, I think, but is there any reason not to renumber those "footnotes" at the same time so that they are vaguely in order and 2 and 7 aren't missing for no good reason?

I try to keep the reviews small so they are easier to review. I made a separate one for that.
And yes, it is way better after reordering :-) https://reviews.freebsd.org/D29934

This revision is now accepted and ready to land.Fri, Jun 11, 4:06 PM

I don't really have time for this right now, so someone else can go ahead and commit it once it's been accepted.

I don't really have time for this right now, so someone else can go ahead and commit it once it's been accepted.

@ngie - you’re holding the PR; will you commit?