DragonFlyBSD

Hiya,

I realize this is quite a simple script, and possibly misses useful features (?). Originally posted to @users, but mailing list line-wraping didn't keep the script fully intact, so copy/paste/test wouldn't of worked

Also, the response on DragonFly Digest encouraged me re-post it here

I've tested it on new installs of 4.8, 5.2, and 5.4, and with installs previously upgraded with `make src-create/src-create-shallow`

It takes this:
------

cd /usr
make src-create
...
make buildworld
make buildkernel
...
make upgrade

To this:
------

/usr/upgrade

Upgrading DragonFly BSD

For more information see:
`man build` `man config`
/usr/src/README /usr/src/UPDATING
http://www.dragonflybsd.org/docs/handbook/

It is possible to run this script without root privileges
Usage: upgrade [configuration]
Configuration is "X86_64_GENERIC"

Latest releases:
[1] DragonFly_RELEASE_5_6
[2] DragonFly_RELEASE_5_4
[3] DragonFly_RELEASE_5_2
[4] DragonFly_RELEASE_5_0
[5] DragonFly_RELEASE_4_8

Select [1-5]:
------

Note: I thankfully just did some retesting, and 'git fetch --depth=1' made git think HEAD was diverged since it didn't have the history to recognize even a single new commit. I've changed the script to do 'git checkout -B RELEASE origin/RELEASE' which should fix the issue, but I will retest DragonFly 4.8 on Monday, since sometimes those flags are not back-compatible

4.8 looks good to me. Feel free to re-download and try it out

Notes:
The script uses 'fetch depth=1' which reduces the initial download by ~250MB. But developers who want full history can do '/usr/upgrade; cd /usr/src; git fetch --unshallow', and sort their own lives out -- so I didn't think it was worth adding to the script as a flag...

If the user aborts the script in the middle of checkout, they may like to just delete /usr/src and try again. So I've added a warning to that effect

I realize this mini-script is unsolicited, and could easily be unwanted for many reasons. That's fine

My thoughts are in the future to maybe look at memory compression / malloc latency / auto configuring wifi. But these really are just thoughts, and not something for this summer

Yup, lets leave the Makefile

Let's go even simpler - if a branch isn't named, as either RELEASE, HEAD, or (Git commit ID), assume that it's an update of whatever branch is currently in place. No menus or choices needed.

For myself personally, I stay on the latest stable release, so I want upgrades to always change the branch 5.4 -> 5.6 -> ... I had basically finished some changes when I got your message (+ a long break for another test install). They give us the latest stable branch with `/usr/upgrade -r 1`. And the prior stable branch with '-r 2'. For the bleeding edge, people can get that with `/usr/upgrade -r 4`, or a specific commit with `/usr/upgrade -r abcdef123`. Maybe the bleeding edge should be '-r 0', but I currently placed it lower so people don't assume it's the first and best option....

Let me at least upload that script (upgrade2)

I agree that people on the bleeding edge only ever want to upgrade their current branch so then a no-branch-change default would be best; but for stable branch users it would just give them a long wait that looks like an upgrade and tells them to reboot etc

Currently if '-r' is specified then there are no menus or choices, which I think is a nice balance. Maybe '-r 4' should move to '-r 0'

Hiya,

I think this gives you what you asked for:

Upgrading to HEAD can be equally done with '-r 0' or '-r unstable' or even '-r master' and '-r 273ce6e304'
Upgrading to the latest release can be done with '-r 1' '-r stable' or even '-r DragonFly_RELEASE_5_6' and '-r e2b890'

So the user can select a relative number, an absolute named branch, a specific commit, or even the bonus phrases of 'stable/unstable'

Feel free to change the wording or anything else; or ask for any changes. I haven't re-tested older dfly versions, but seems good on 5.6

Make sure user has options when network offline