A tool to make easier the upgrade under pkgbase

[Emrion]

Here we are. This is the first version of pkgb-update. A tool that mimics in some ways freebsd-update but for pkgbase systems.

GitHub - Emrion/pkgb-update: A tool to make upgrade with pkgbase easy

A tool to make upgrade with pkgbase easy. Contribute to Emrion/pkgb-update development by creating an account on GitHub.

github.com

pkgb-update​

pkgb-update is the counterpart of freebsd-update, but for pkgbase systems.
It's a script that updates (that's simple) and mostly upgrades the FreeBSD OS.

pkgbase opens some upgrades (and updates) that were not supported otherwise than compiling the code source.
pkgbase dramatically speed up the upgrade comparing to freebsd-update.
Nevertheless, pkgbase has its own drawbacks. One of them is the complexity of the commands to type to upgrade.
This is where a tool like pkgb-update has a role to play.

pkgb-update is able to upgrade from RELEASE to RELEASE, but also from:

• RELEASE to RC
• RC to next RC
• RELEASE or RC to STABLE
• Any to CURRENT

It lacks ALPHA and BETA versions, this will come later.

You are free to use, take ideas, copy some portions of code and abuse.

 

[mer]

Very nice.

 

[fjdlr]

Cool

 

[Emrion]

As in my agenda, I tried to downgrade from:

- 15.1-RELEASE to 15.0-RELEASE-p10: works*.
- 15-STABLE to 15.1-RELEASE: works*.
- 15-STABLE to 15.0-RELEASE-p10: works*
- 16-CURRENT to 15.1-RELEASE: doesn't work. 'Shared Object libXest.so.6" not found' at restart.

(*) There is a downgrade of pkg you see because the database version is lower.

Globally, even if there are some success, it's wiser to not allow downgrades.

Note: it's tested on a virtualbox VM installed from 15.0-RELEASE with pkgbase. It's a default installation with kde. The virtualbox-ose-additions on 16-CURRENT is panic'ing' the kernel, so I deactivate it for CURRENT. I installed drm-61-kmod just to see the kmods upgrade.

 

[fahrenheit]

Emrion, downgrades as you mention work, the issue is whether or not the sqlite database is understood by both the source and the target branch. Other than that a downgrade from 16-CURRENT to 15-STABLE should work, you just need to follow the order:

1. pkg upgrade -f -r FreeBSD-base
2. pkg upgrade -f -r FreeBSD-ports-kmods
3. pkg upgrade -f -r FreeBSD-ports

Although, I would highly advise a step where the gpu drivers get removed from rc.conf because, during minor releases even with ports-kmods at latest the drm drivers are usually broken

 

[Emrion]

Emrion, downgrades as you mention work, the issue is whether or not the sqlite database is understood by both the source and the target branch. Other than that a downgrade from 16-CURRENT to 15-STABLE should work, you just need to follow the order:

1. pkg upgrade -f -r FreeBSD-base
2. pkg upgrade -f -r FreeBSD-ports-kmods
3. pkg upgrade -f -r FreeBSD-ports

Although, I would highly advise a step where the gpu drivers get removed from rc.conf because, during minor releases even with ports-kmods at latest the drm drivers are usually broken

It's exactly what I do* and this doesn't work from CURRENT. I mean, it boots but I have errors concerning shared libraries... Not good at all.

(*) Edit: a doubt come to me. Would it be possible there was no downgrade of packages from FreeBSD-ports? I'm unsure if I made pkgbase tag this downgrade as Major or not... I will check this.

 

[mer]

I think this is a very good example of "see problem, think about problem, create tool to fix/work around problem". Much like updating bootloaders.

 

[Emrion]

Emrion, downgrades as you mention work, the issue is whether or not the sqlite database is understood by both the source and the target branch. Other than that a downgrade from 16-CURRENT to 15-STABLE should work, you just need to follow the order:

1. pkg upgrade -f -r FreeBSD-base
2. pkg upgrade -f -r FreeBSD-ports-kmods
3. pkg upgrade -f -r FreeBSD-ports

Although, I would highly advise a step where the gpu drivers get removed from rc.conf because, during minor releases even with ports-kmods at latest the drm drivers are usually broken

You were right. pkgb-update didn't understand that a downgrade can be a Major downgrade.
So, no more lib problem, but many others. Some softwares have been deinstalled and kde didn't launch. It wasn't difficult to correct the thing, that said and anyway, the OS part is ok, it seems.

Which leads to the same question: is it wise to leave the possibility to downgrade? How to know if the pkg database will work after downgrade from a given FreeBSD version to another one (before to allow this downgrade)?
How many people will use such a feature?

 

[fahrenheit]

I would advise against leaving it. Pkgbase has enough detractors as is, no need to give them more reasons to complain

Users that are set on downgrading will do it anyway and are, probably, knowledgeable enough to unbreak their system if needed (or they will learn new tricks, like myself).

 

[Emrion]

It seems that the problem about the pkg database version isn't really a problem.

Looking at the pkg code libpkg/pkgbd.c, I see:

if (db_version > DBVERSION) {
        if (db_version / 1000 <= DB_SCHEMA_MAJOR) {
            /* VIEWS and TRIGGERS used as compatibility hack */
            pkg_emit_error("warning: database version %" PRId64
                " is newer than libpkg(3) version %d, but still "
                "compatible", db_version, DBVERSION);
            return (EPKG_OK);
        } else {
            pkg_emit_error("database version %" PRId64 " is newer "
                "than and incompatible with libpkg(3) version %d",
                db_version, DBVERSION);
            return (EPKG_FATAL);
        }
}

I scrolled a little up and saw:

 Anyone wishing to make a schema change that necessitates incrementing
   DB_SCHEMA_MAJOR must first present every other pkgng developer with one
   of the Golden Apples of the Hesperides

I understand this isn't something we will stumble on this century.
This leaves the downgrade feature open... Something fun if not useful.

 

[fahrenheit]

It seems that the problem about the pkg database version isn't really a problem.

Looking at the pkg code libpkg/pkgbd.c, I see:

if (db_version > DBVERSION) {
        if (db_version / 1000 <= DB_SCHEMA_MAJOR) {
            /* VIEWS and TRIGGERS used as compatibility hack */
            pkg_emit_error("warning: database version %" PRId64
                " is newer than libpkg(3) version %d, but still "
                "compatible", db_version, DBVERSION);
            return (EPKG_OK);
        } else {
            pkg_emit_error("database version %" PRId64 " is newer "
                "than and incompatible with libpkg(3) version %d",
                db_version, DBVERSION);
            return (EPKG_FATAL);
        }
}

I scrolled a little up and saw:

 Anyone wishing to make a schema change that necessitates incrementing
   DB_SCHEMA_MAJOR must first present every other pkgng developer with one
   of the Golden Apples of the Hesperides

I understand this isn't something we will stumble on this century.
This leaves the downgrade feature open... Something fun if not useful.

Yeah, I noticed when I did my desperation downgrades that it worked. But it's nice to know that someone thought about these uses
In any case as pkg is from ports and those are more or less in sync with all FreeBSD versions one can bypass most issues if after doing the downgrade the first command is pkg upgrade pkg.

 

[Emrion]

It was too temping. pkgb-update is now able to do downgrades.

I tested: 16-CURRENT -> 15-STABLE -> 15.1-RELEASE -> 15.1-RC2 -> 15.0-RELEASE

I also added the scan of .pkgnew files. They appear often and often for nothing. For example, you added an user in the wheel group. pkg leaves the current conf files and copy in .pkgnew files what it would be instead. In practice, you delete the .pkgnew files once you undertand what happened. Cases where you have to do a real merge should be rare, I think.