On Wed, Apr 20, 2016 at 11:43:00AM +0100, Matthew Seaman wrote:
> 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
> 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.
This is about RELENG, what about STABLE and CURRENT?
> 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.
New numbering scheme is very hard problem...
email@example.com mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"