Future upgrade from 14.x to 15 - pkgbase?

fmc000 said:
What I like most of FreeBSD is that the kernel and _all_ the userland are a coherent monolith. If you make a mistake of you simply want to restart from scratch the solution is just a tar command away. It is my understanding that this will not be possible anymore with pkgbase (I may be wrong, of course, and I thank in advance everyone that will correct me if this is the case).
Click to expand...
I untar the sets for using them for remote booting. I hope there will be an alternative ...

Emrion said:
There are serious advantages using pkgbase: speed of updating/upgrading. It took only a couple of minutes comparing to an hour or more with freebsd-update.
Click to expand...
That is not an advantage of pkbase (that I do not know), but a disadvantage of freebsd-update.
 
hruodr said:
Perhaps untaring the sets.
Click to expand...
I've not done that, I know a lot of people do that sometimes for things like a VM.
If base still contains "everything" like it does now, pkgbase should not affect that. pkgbase is simply an accounting of the contents.
 
So, thanks to a post from a person I learned to trust in this forum I realized that I was making a fuss about nothing and thus I decided to try pkgbase on my second laptop, not my main one, using pkgbasify.lua .

It worked absolutely FLAWLESSLY. I created a new BE before launching it but it was not necessary as the utility prompts you to create one.

It's also very fast, my laptop is 15 years old and it supports only NG wifi and despite that I had the system up&running in less than two minutes. Impressing indeed.

Of course it will require a lot of testing before I switch on my main laptop but everything is running at least as before.

Only nitpick: at the first reboot lightdm did not honor the autologin configuration and asked for my password. After removing all .pkgbase files, loader.hint and a second reboot all was as before.

Just my 2cents.
 
fmc000 said:
So, thanks to a post from a person I learned to trust in this forum I realized that I was making a fuss about nothing and thus I decided to try pkgbase on my second laptop, not my main one, using pkgbasify.lua .

It worked absolutely FLAWLESSLY. I created a new BE before launching it but it was not necessary as the utility prompts you to create one.

It's also very fast, my laptop is 15 years old and it supports only NG wifi and despite that I had the system up&running in less than two minutes. Impressing indeed.

Of course it will require a lot of testing before I switch on my main laptop but everything is running at least as before.

Only nitpick: at the first reboot lightdm did not honor the autologin configuration and asked for my password. After removing all .pkgbase files, loader.hint and a second reboot all was as before.

Just my 2cents.
Click to expand...
Thanks for posting feedback. My opinion only, I think it may wind up to "it's different", there are some very legitimate concerns around coherency for a "release" and the more exposure/testing is overall better.
 
rbranco said:
Because CVS sucks. It's centralized and slow as hell.
Click to expand...
In some ways yes, in some ways no.
  • Its a better VCS than 'nothing' in base (i.e fetch(1))
  • Centralized is fine for many projects and use-cases
  • Its faster than git where sparse checkouts tend not to be the norm
  • Its "database" is plain-text RCS files. Which are easier to fix if there is corruption
 
kpedersen said:
In some ways yes, in some ways no.
  • Its a better VCS than 'nothing' in base (i.e fetch(1))
  • Centralized is fine for many projects and use-cases
  • Its faster than git where sparse checkouts tend not to be the norm
  • Its "database" is plain-text RCS files. Which are easier to fix if there is corruption
Click to expand...
It's not faster. I use it myself to checkout the openbsd_77 branch and it takes ages even when no changes are present. There's simply no way it can be faster than git, which has a sparse-checkout command anyway.

I have never experienced corruption in the git database and it should be easy to fix because it's decentralized. It supposed to store stuff that you push to a git forge anyway.

With git you never lose anything even when you overwrite commits or mess up with branches. Everything is available with `git reflog` until you run the garbage collector.
 
rbranco said:
It's not faster. I use it myself to checkout the openbsd_77 branch and it takes ages even when no changes are present. There's simply no way it can be faster than git, which has a sparse-checkout command anyway.
Click to expand...
Yeah, as mentioned sparse checkout tends not to be the norm, because there are a number of limitations if you do use it; particularly if you work between a number of branches.

Which means for an OpenBSD source tree, you are left between a checkout that is either a couple of hundred megs with CVS or a checkout which is well over 1 GB with Git. This is all dependent on your internet connection speed but the reduced bandwidth approach is likely to be faster.
rbranco said:
I have never experienced corruption in the git database and it should be easy to fix because it's decentralized. It supposed to store stuff that you push to a git forge anyway.
Click to expand...
Its rare. Its mostly important if you host the server yourself. I would much rather attempt to fix a CVS repo than a Git one. In either case, having multiple copies of the repo can sidestep this risk (and Git does make this easier).
 
cracauer@ said:
Does pkgbase store its database separately from ports pkg?
Click to expand...
Code: 
[15:23][fmc000@tu45b-freebsd ~]$ find /var/db/pkg/
/var/db/pkg/
/var/db/pkg/vuln.xml
/var/db/pkg/repos
/var/db/pkg/repos/XLibre
/var/db/pkg/repos/XLibre/db-journal
/var/db/pkg/repos/XLibre/db
/var/db/pkg/repos/XLibre/lock
/var/db/pkg/repos/XLibre/meta
/var/db/pkg/repos/FreeBSD-ports
/var/db/pkg/repos/FreeBSD-ports/lock
/var/db/pkg/repos/FreeBSD-kmods
/var/db/pkg/repos/FreeBSD-kmods/db-journal
/var/db/pkg/repos/FreeBSD-kmods/db
/var/db/pkg/repos/FreeBSD-kmods/expired_packages.ucl
/var/db/pkg/repos/FreeBSD-kmods/groups.ucl
/var/db/pkg/repos/FreeBSD-kmods/meta
/var/db/pkg/repos/FreeBSD-kmods/lock
/var/db/pkg/repos/FreeBSD
/var/db/pkg/repos/FreeBSD/lock
/var/db/pkg/repos/FreeBSD/meta
/var/db/pkg/repos/FreeBSD/groups.ucl
/var/db/pkg/repos/FreeBSD/db-journal
/var/db/pkg/repos/FreeBSD/db
/var/db/pkg/repos/FreeBSD/expired_packages.ucl
/var/db/pkg/repos/FreeBSD-base
/var/db/pkg/repos/FreeBSD-base/meta
/var/db/pkg/repos/FreeBSD-base/lock
/var/db/pkg/repos/FreeBSD-base/db-journal
/var/db/pkg/repos/FreeBSD-base/db
/var/db/pkg/local.sqlite
[15:24][fmc000@tu45b-freebsd ~]$
 
kpedersen said:
Yeah, as mentioned sparse checkout tends not to be the norm, because there are a number of limitations if you do use it; particularly if you work between a number of branches.

Which means for an OpenBSD source tree, you are left between a checkout that is either a couple of hundred megs with CVS or a checkout which is well over 1 GB with Git.
Click to expand...
Git is faster for everything. Cloning a full repo with all branches is faster than a cvs checkout of a single branch. Sparse checkouts are also faster. Git transfers packed binary blobs that contains the files while cvs uses rsync to transfer individual files.

kpedersen said:
Its rare. Its mostly important if you host the server yourself. I would much rather attempt to fix a CVS repo than a Git one. In either case, having multiple copies of the repo can sidestep this risk (and Git does make this easier).
Click to expand...
I haven't felt the need to fix a git repo ever. If you mess up, you can just clone it again.
 
You must log in or register to reply here.
Back
Top