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

[Thomas Nikolajsen via Redmine]

Issue #2527 has been updated by thomas.nikolajsen.


marino wrote:
>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.
I don't agree; supplied patch simplifies (& fixes bugs): fewer lines with simple logic & better doc.

>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
The backupworld-auto-clean* targets are meant to be manual only (GC).

>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.
It is not perfect, but your solution was worse & doc/commit message didn't indicate what purpose was;
we need to find a better way if it is important.

>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..
There is no standard case, we need to make it work for all supported setups,
especially if auto-backup will be on by default.

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

>A local backup wouldn't need several levels of directories filled with "hostname" and "arch"
>since neither will ever change.  It implies that it would be backed up in a common area with
>multiple hostnames and archs.
>(and do we need to protect for a case where the there are two arches with the same hostname?).
>Seems like overkill for the default.

We need a simple scheme which works in all supported setups: NFS or local MAKEOBJDIRPREFIX;
there is no mechanism to change auto-backup dir, so we don't have a default.

IMO the scheme I suggest in patch matches what we need,
but if you have other suggestion, please show it.

We could introduce mechanism to change auto-backup dir, if it is needed.

Also, even for local MAKEOBJDIRPREFIX we do need TARGET_ARCH to influence auto-backup dir,
as we support cross builds.

Hostname isn't a perfect match, for what we need, but it is close, as we have no system UUID.
If hostname is changed, user can easily find backup to restore from: it is all documented.

We could turn on auto-backup on by default, when we have a worked out implementation;
I'm not sure we will get there for the release.

My intention is to commit something like the supplied patch before release,
if we don't agree on other fix; alternatively we could backout backupworld for now &
re-introduce a reworked version at a later time.

 -thomas
----------------------------------------
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