On Tue, Mar 08, 2016 at 03:40:16PM +0300, Slawa Olhovchenkov wrote:
> On Wed, Mar 02, 2016 at 11:54:29PM +0000, Glen Barber wrote:
> > To obtain the sources for testing, please use the projects/release-pkg
> > branch:
> > 
> >  # svn co svn://svn.freebsd.org/base/projects/release-pkg /usr/src
> > 
> > The projects/release-pkg branch is (at this time) in sync with head
> > revision r296327.
> > 
> > After checking out the project branch, build the userland and kernel as
> > normal with the 'buildworld' and 'buildkernel' targets.  Afterward,
> > packages can be created with the 'packages' target.
> > 
> >  # cd /usr/src
> >  # make [make flags] buildworld
> >  # make [make flags] buildkernel
> >  # make packages
> > 
> > At present, the base system consists of 755 packages with the default
> > build (empty src.conf(5) and make.conf(5)) for amd64.  The number of
> > packages depends on several factors, but for most cases a runtime binary
> > is split into several components.  In particular, most shared libraries
> > are individually packaged, in addition to debugging symbols, profiling
> > libraries, and 32-bit packaged separately.
> > 
> > The package repository will be created within /usr/obj/usr/src/repo by
> > default.
> I am get snapshot .iso for install test setup in VirtualBox and using
> projects/release-pkg for sources. After make buildworld buildkernel
> packages and pkg install '*' I am have some words.
> I am not developer, I am like maintenance services. I am do maintaing
> systems more ten 20 years, some systems maintainig more ten 10 year
> continuous, some systems got for maintenance after years unmaintening.
> All of this give some requirement and vision different from
> developers. Please, do not reject this!
> First, you do collocal work, thanks!
> I am don't check all, but already found some stranges:
> Package FreeBSD-clibs-development contain /usr/lib/libthr.so,
> /usr/lib/libedit.so and etc (and same in other packages).

Correct.  The libraries in the 'clibs' package must be installed before
the rest of the system can be safely upgraded, to ensure consistency
with the core runtime libraries.

> Misspeling FreeBSD-debug, FreeBSD-development and FreeBSD-profile as
> FreeBSD-runtime-debug, FreeBSD-runtime-development and 
> FreeBSD-runtime-profile?

I am not sure why this was originally named as they are, but this can be

> I am reseach spliting to package and try some aggregation:
> NumPkgs  tarSize(MB)  flatSize(MB)  Aggregation
> 1          30.7            102      FreeBSD-kernel-generic-release
> 1          57.1            331      FreeBSD-kernel-generic-debug
> 1           2.8              5.4    FreeBSD-clibs
> 1         3.5             24      FreeBSD-clibs-development
> 1           2.4                   11      FreeBSD-clibs-debug
> 1         1.3              9.8    FreeBSD-clibs-profile
> 1          20.7                  103      FreeBSD-runtime
> 1         5.9             38.1    FreeBSD-development
> 1         2.9              2.8    FreeBSD-runtime-manuals
> 1        14.9             65      FreeBSD-debug
> 1         2.2             12.5    FreeBSD-profile
> 1        24.3             93      FreeBSD-clang
> 1         8.7             66      FreeBSD-clang-debug
> 116      19.0             80      FreeBSD-*
> 89        3.2             14      FreeBSD-*-development
> 110      12.5             61      FreeBSD-*-debug
> 85        2.8             13      FreeBSD-*-profile
> 85        6.0             18      FreeBSD-*-lib32-*
> 88        7.4             30      FreeBSD-*-lib32-development
> 84       11.6             43      FreeBSD-*-lib32-debug
> 85        5.8             24      FreeBSD-*-lib32-profile
> I.e -development is substantially less of main package and don't need
> separatly (and many .so incorrectly packaging into -development).
> Same as -profile vs -debug (and -profile useless w/o -debug).

Regarding the .so files, I am not clear on the original intent behind
separating the actual shared library from the installed symbolic link to
the real shared library, but in my investigation into this, only the
symlinks are provided by the '-development' package.

For example:

 root@pkgbase:/ # file /usr/lib/libjail.so
 /usr/lib/libjail.so: symbolic link to ../../lib/libjail.so.1
 root@pkgbase:/ # pkg shlib libjail.so
 No packages provide libjail.so.
 No packages require libjail.so.
 root@pkgbase:/ # pkg shlib libjail.so.1
 libjail.so.1 is provided by the following packages:
 libjail.so.1 is linked to by the following packages:

Moving them to the package that installs the shared library itself
should be fairly easy to do.

Regarding '-profile' and '-debug' package separation, it is possible to
install the debugging files without requiring the profiling libraries
now, so I think keeping them as separate packages is the best way to
achieve this.  (Note, profiling libraries will not be installed with
WITHOUT_PROFILE=1 in src.conf(5)).

> Manual must be installed always, IMHO (size is small and version of
> manual must matcj version of utility).

This is similarly broken up by package, at least where it has been found
so far.  The jail.conf(5) manual is only installed if the 'FreeBSD-jail'
package is installed, for example.

 root@pkgbase:/ # pkg which /usr/share/man/man5/jail.conf.5.gz
 /usr/share/man/man5/jail.conf.5.gz was installed by package

> Packaging of individual utilites is useless (total 19MB vs
> 30.7+2.8+20.7+2.9) and incorrect (for example, WITHOUT_ACCT not only
> don't build accton/lastcomm/sa but also cut off accaunting code from
> kernel for space saving and perforamce).

Packaging individual utilities is not useless, depending on who you ask.
One of the first replies I received when starting separating userland
utilities into separate packages was further splitting rwho(1) and
rwhod(8) into different packages, the use case being not necessarily
needing (or wanting) the rwho(1) utility on systems where rwhod(8) runs.

> I am propose don't distinct profile and debug, development and main
> package.
> I am propose divide only to FreeBSD-kernel, FreeBSD-clibs (clibs,
> runtime and manuals), FreeBSD-clang, FreeBSD-lib32.

This will make updates for SAs and ENs too large.  This is part of the
reason the packages were split up as they have been so far (and will
continue to be further split as progress is made).

If the argument is simply "there are too many packages", see one of the
previous replies in this thread that discusses the background on why
this decision was made.

But that aside, trying to make everyone happy will turn out to make no
one happy.

> Dividing to many packages is anoyning on install and maintancing (what
> exact keys of this utilites this version?! stupid admin don't install
> manuals!)
> About use cases. I am try to imagine different use cases and don't
> found answer how do this:
> 1. package building as `make packages` witch version as timestamp of
> start buildworld. I.e. on every buildworld every package will be
> rebuild, take new version and will be reinstaled. Where is profit of
> package spliting?

This is the case for 11-CURRENT.  The PKG_VERSION evaluates the BRANCH
from Makefile.inc1 to determine if it should use the timestamp.  (Since
-CURRENT is a fast-moving target, and we recommend keeping the userland
and kernel in sync, this makes sense, at least to me.)

> 2. After src.conf change some package don't build. Where analog of
> `make delete-old delete-old-libs`?

I believe 'pkg autoremove' should handle this, but I will check.

> 3. After src.conf chanege some (WITHOUT_ACCT for example) some
> packages can't be installed. How handle this?

Have you run into this?  If so, it needs to be investigated.  But
otherwise, the generated packages respect make.conf(5) and src.conf(5),
so this should not happen in theory.

> 4. How install debug symbols after installing separately set of
> packages? Not all *-debug*- and don't selecting all 200 packages
> individualy?

Could you clarify what you mean a bit more?  Specifically, I am unclear
of the order of events you mean.

> 5. Take system installed by unknow person (ex: ISP support 5 years
> ago). Try to write program. Don't find nothing for this. Version is
> 11.0-BETA3. How to install required packages? For system w/o inetrnet
> connectivity and with lost install media?

The plan at the moment is to include pkg(8) in the repository with the
base system.  This will also be required for architectures we do not
have an upstream package repository (powerpc, for example).  This is
handled by the 'package-pkg' target at the moment.

> As for windows (please found in garbage CD with exact version and
> insert in lost CD-ROM)?
> May be preserve for this all packages in some places on HDD?

I am having trouble parsing these two sentences.  Could you please

> 6.  pkg which /etc/ssh/ssh_config
> /etc/ssh/ssh_config was not found in the database

There are may occurrences of this at the moment.  Configuration file
merging needs to be resolved in pkg(8) before we can safely add files
like sshd_config(8) to the 'FreeBSD-ssh' package.

> What?! How to handle this? What is instead of mergemaster?
> (etcupdate currently to dangerous, I am totaly destroed one host by
> etcupdate. Also, current database of etcupdate is very strange).

We use etcupdate(8) in the FreeBSD infrastructure, and have not run into
such problems.


Attachment: signature.asc
Description: PGP signature

Reply via email to