[DragonFlyBSD - Bug #2527] Re: git: build: implement automatic world backups

John Marino via Redmine bugtracker-admin at leaf.dragonflybsd.org
Mon Apr 8 09:52:13 PDT 2013


Issue #2527 has been updated by marino.


The original incarnation of this is similar to your patch, but dillon asked for it to be reworked and simplified.  Now it's blown up in complexity again.

On the "makefile" patch, IIRC, you're only supposed to document targets that you can actually run.  You can't "make backupworld-auto-clean" for instance, so it's would only appear on Makefile.inc

On quick glance, it seems that by removing the timestamp to solve one problem, you reintroduced another problem: The auto-backup (if enabled) will occur every time you "make installworld".  In the case where you buildworld once and "make installworld" many times, this is undesired.

The use of a tarball is probably an improvement especially if it allows backup of make, cp, etc, and I suspect it's a key in dealing with the chflags/nfs issue.

I would disagree (also based on Dillon's direction) that the AUTO_BACKUP is off by default.  
I'm also not sure about the redefinition of the AUTO_BACKUP default.  That seems to favor an NFS implementation.  Wouldn't the standard case be a single machine with local backups?  In that case, the default is a bit obnoxious.  Not something to fall on a sword for..

I think it's a big step in the right direction.

----------------------------------------
Bug #2527: Re: git: build: implement automatic world backups
http://bugs.dragonflybsd.org/issues/2527

Author: c.turner1
Status: In Progress
Priority: Normal
Assignee: 
Category: 
Target version: 


On 02/17/13 14:43, John Marino wrote:

>      Additionally, every time the "installworld" target is executed, the same
>      directories will be automatically backed up at the location of
>      ${MAKEOBJDIRPREFIX}/world_backup .  These directories could be restored
>      with the new make target "restoreworld-auto".

Bug: This breaks on NFS object trees as the copy tries to set flags,
which can't be done over NFS

Also,

1) getting an 'off button' back for this would be swell
2) build(7) should probably be updated with whatever the final result is.

personally, I'd prefer this was optional behavior with an 'on' switch,
(e.g. it seems sort of like a 'developer setting' like CFLAGS, etc)

but, that's me.

sorry to back seat drive with no attched patch - lifes a bit hectic ATM.

Cheers,

- Chris


-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account



More information about the Bugs mailing list