Project

General

Profile

Bug #3197

DragonFly upgrades

Added by tse 3 months ago. Updated 2 months ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
Feature request
Target version:
-
Start date:
07/13/2019
Due date:
% Done:

0%

Estimated time:

Description

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]:
------


Files

upgrade (3.42 KB) upgrade tse, 08/08/2019 10:23 PM

History

#1

Updated by tse 3 months ago

  • File upgrade added

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

#2

Updated by tse 3 months ago

  • File deleted (upgrade)
#3

Updated by tse 3 months ago

  • File deleted (upgrade)
#4

Updated by tse 3 months ago

  • File upgrade added

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

#5

Updated by justin 3 months ago

tse wrote:
> 4.8 looks good to me. Feel free to re-download and try it out

I am not sure how to describe this exactly, but I'm thinking it would be better as an action - upgrade --release for the current release version, 'upgrade --bleedingedge' or similar for HEAD. Kitchen sink scripts that handle maintenance are good but they tend to grow and then collapse under their weight.

I may be overthinking this.

#6

Updated by tse 3 months ago

You're right, some people will want HEAD, and seeing @yellowrabbit do a commit bisect, a one liner upgrade to named commit would also be nice

I wanted to avoid required flags, so people don't have to re-look them up, but an optional flag like [ -r HEAD | COMMIT | RELEASE ] would make the script more automatable, so maybe something like:

/usr/upgrade [-r release] [configuration]
Configuration is "X86_64_GENERIC"
Select a release:
[1] DragonFly_RELEASE_5_6
[2] DragonFly_RELEASE_5_4
[_] Enter a specific commit like HEAD or abcdef123

If people don't pass a [ -r RELEASE ], then the script will give the release options to select from

Would something like that be what you're after?

> Kitchen sink scripts that handle maintenance are good but they tend to grow and then collapse under their weight.

Agreed

This script partly replicates the functionality in /usr/Makefile. Should it totally replicate the functionality (dports-create, dports-download), so the Makefile can be removed? Or should that functionality be retained elsewhere -- it's not something I've used before

#7

Updated by justin 3 months ago

tse wrote:
> If people don't pass a [ -r RELEASE ], then the script will give the release options to select from

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.

> This script partly replicates the functionality in /usr/Makefile. Should it totally replicate the functionality (dports-create, dports-download), so the Makefile can be removed? Or should that functionality be retained elsewhere -- it's not something I've used before

In a perfect world, we'd have this all under the same interface - 'make (whatever)' would do the appropriate actions. People are very used to having the make function work, so I'm leery of removing that functionality... but on the other hand, I am not the one doing all the work. Do what you would enjoy working on and let's see what other people think.

#8

Updated by tse 2 months ago

  • File upgrade2 added

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'

#9

Updated by tse 2 months ago

Or something like '-r stable' and '-r unstable' would be easy to add

#10

Updated by tse 2 months ago

  • File upgrade3 added

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

#11

Updated by justin 2 months ago

tse wrote:
> Feel free to change the wording or anything else; or ask for any changes.

This works well - I imagine 95% of the use cases are going to be "upgrade within current version" or "move to next release" so I want that to be as little guesswork as possible.

I'm going to be on the road for a little while yet - part of the reason for my slow responses. I won't be able to try this out... maybe I can gin up some testers.

#12

Updated by tse 2 months ago

  • File deleted (upgrade)
#13

Updated by tse 2 months ago

  • File deleted (upgrade2)
#14

Updated by tse 2 months ago

#15

Updated by tse 2 months ago

  • File deleted (upgrade3)

Also available in: Atom PDF