[CFT] packaging the base system with pkg(8)

[Matthew Seaman]

On 2016/04/19 08:54, David Chisnall wrote:
> The big advantage of going with small packages initially, however, is
> that it will allow us to get some data on what the correct groupings
> are.  If we have large packages, then it’s very hard to tell which
> subsets of the packages people want.  That’s exactly the situation
> that we’re in now: we know some people don’t want docs or games, but
> that’s about all that we know.  It’s easy to move to a model where we
> have *fewer* packages in the future, but it’s harder to split them.
> That also applies to dependencies.  If I know that a port depends on
> the shell, then it’s easy to update it from depending on a sh package
> to depending on a core system utilities package automatically, but
> it’s very hard to do an automatic update in the other direction.

Exactly.  Bapt's talks[+] about the design decisions behind how base was
divided up into packages explain very clearly why the situation now is
as it is.  Basically *any* way of dividing up the base system into
packages would raise the hackles of some subset of the user base.  So he
chose to create a large number of small packages for maximum flexibility
and also supply a range of different meta-packages allowing installation
of various useful package sets as a simple operation.  The current base
package builds don't actually include those meta-packages yet, so it's
impossible to say right now how that will work out.

Yes, this is the first attempt at creating a package hierarchy for base,
and it's going to be buggy.  The way things are set up should mean that
those bugs are only annoyances, and not show stoppers.

Complaining purely about the /number/ of packages the base is divided
into is not productive: certainly there are some packages that could be
merged or otherwise eliminated, but until people come up with concrete
proposals about the details of doing that, little progress is going to
be made.

Yes, I agree that the way pkg(8) displays the package data certainly
could be improved.  The base packaging setup actually implements a idea
we have been talking about with reference to the ports tree: that is
'sub-packages.'[*]  What's missing is a neat way of displaying and
handling a package that consists of a collection of sub-packages; at the
moment they're all shown as completely independent packages, which works
as far as the mechanics of installing and maintaining your server but
doesn't necessarily give the best user experience.

	Cheers,

	Matthew

[+] https://youtu.be/Br6izhH5P1I?list=PLWW0CjV-TafY0NqFDvD4k31CtnX-CGn8f

[*] So that one port could compile into several different packages,
including separate pkg blobs for docs, examples, shared libraries,
debugging symbols, C/C++ header files, various different extras enabled
by options settings and (not least) the actual program binaries or
scripts.  By default you'ld get all of the above simply by installing
the top-level package -- which would result in the same filesystem
content as when using the existing monolithic packages.  However you
could install or delete any of those sub-packages separately as
required.  Means, for instance, you could install multiple different ABI
versions of a shared library simultaneously, something you can't do
nicely with either ports or packages today unless there's some special
hack to allow it.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 972 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-pkgbase/attachments/20160419/49111b87/attachment.sig>