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 > 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. 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...Received on Wed Apr 20 2016 - 10:24:02 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:04 UTC