On 04/20/16 10:48, Slawa Olhovchenkov wrote: > While number of packages don't see outside internal -- this is > irrelevant. > After possibility of update individual package -- nuber of packages is > impotant. > Take fresh 11.0. Before 11.1 update only kernel. What you system have? > 11.0? 11.1-RC3? How you name it? How identify it for take support on > forum or mail list? > > How name system, updated all w/o compiler? or only some services? > Currently we have simple naming: > > 10.3-RC1, 10.3-RELEASE, 10.3-p7, 10.3-STABLE r123456. > This is shortly and clearly identify system to anyone. > > How do this with many packages?
Hmmm.... Good point.
At release time, a set of packages will be generated. These will all
have the version number of the release eg. 11.0. That's simple and
unambiguous.
Subsequently adding patches will add a patch level to the version, so
11.0-p1, 11.0-p2 exactly as now. Only patches that affect the kernel
will cause the output of uname(1) to show the new patch level, but
updates to user land should be reflected in the output of
freebsd-version(1). That's exactly the same as now, and assuming you,
as an end user, install the default set of FreeBSD packages and apply
all the patches as they come out, then there should be no problem.
This implies that /every/ patchset will include an update to the package
containing freebsd-version.
What packaging base does do is allow you to be selective in the patches
you apply. So, for instance if patch -p1 was not relevant to you, you
might not install it. So you could end up with a system where you
hadn't installed patches -p1 -- -p9 but you did install patch -p10. The
freebsd-version(1) output would presumably show the system as 11.0-p10
-- but that's certainly not the same as a system with all of those
patches -p1 to -p9 applied. Or you could just install the updated
freebsd-version(1) package and have your system blatantly lie about its
patching status.
So, yes, this does change the meaning of the version number string.
It's morally equivalent to tracking the releng/11.0 branch in SVN but
compiling your system with various WITH_FOO or WITHOUT_BAR flags, and
possible local modifications to the code base to back out certain
commits. It's still 11.0-SOMETHING but it's not clear exactly what that
something should be. Hopefully people that do such things will be
sufficiently technically sophisticated to be able to characterize their
problems based on the versions of any relevant FreeBSD packages.
On the release of 11.1 there would be a complete new set of system
packages generated, and the upgrade process would install the new
versions of those packages all round, even if the content of an
individual package was identical to the one in 11.0. There's probably a
handy optimization where we compare the before and after checksums for
package files and don't overwrite on disk what is identical between
package versions, but do update all of the bookkeeping in the pkgdb.
Cheers,
Matthew
signature.asc
Description: OpenPGP digital signature
