Distribute FreeBSD via packages instead of "global" tarballs

[Matthew Seaman]

On 16/07/2013 11:59, Florent Peterschmitt wrote:
> Le 13/07/2013 19:00, Matthew Seaman a écrit :
>> On 13/07/2013 15:36, Florent Peterschmitt wrote:
>>> Is it possible to package FreeBSD distribution under little packages,
>>> aiming easy and small upgrades ?
>>>
>>> Or this has already been thought ?
>>
>> This is certainly technically possible, and it's something there's been
>> occasional speculation about; but as far as I know, no one has yet come
>> up with a demonstration setup.
>>
>> There are a number of practical problems that would need sorting out --
>>
>>    * pkg isn't part of the base system -- by design -- which makes it
>>      tricky to use to register installing base system components on a
>>      bare metal system.
> 
> But it will be in FreeBSD 10 ?

No.  pkg is the default packaging system in FreeBSD 10, but it isn't
part of the base system.  Think of it as a ports component, rather than
a base system component.  Of course, that design decision was made given
the assumption that the only thing pkg would be used for is managing
add-on packages; ie. stuff that by definition is not in base.

Doesn't preclude using it for base, but, like I said, a bit trickier to
deal with.

>>    * Similarly, pkg pretty much ignores the facilities and shared
>>      libraries from base when calculating dependencies and so forth for
>>      ports.  If base is pkg-ised, should that still be the case?
> 
> Hum. It will be a lot of work to turn the base system in a port-like
> way. Maybe it would be simpler to have some "diff" packages, a bit like
> freebsd-update does but with pkg.

Well, we are working towards a generic 'provides/requires/conflicts'
dependency scheme.  Base system packages could just provide a symbolic
'FreeBSD-10.0-base' token that ports packages could require.  Actually,
that's quite an interesting idea even if we don't supply the base system
as a bunch of pkgs.  Hmmm....

>>    * Given that the base system is divided up into numerous smaller
>>      packages, should those packages be registered in the same database
>>      as is used for ports? (ie. /var/db/pkg/local.sqlite)
> 
> Certainly not. If an rm -rf /usr/local/* /var/db/pkg/local.sqlite can
> clean up the system of every third-party software, base components
> doesn't have their place with them. *BSD always separate base from the
> rest, why this should change here ?

Well, having the 'provides/requires/conflicts' dependency stuff all
registered in the same database makes using the package solver against
dependency trees using base system components workable without any
faffing around.  Straight up deletion of /var/db/pkg/local.sqlite is
certainly not recommended as a routine procedure in any case: 'pkg
delete -fa' is much better.

Pursuing the logic of this: we'd probably have a flag in the DB to
identify base system packages and so be able to treat them differently
to regular packages.

>> Packaging the base system is an idea that has been floating around for a
>> long time -- since long before pkg was conceived, certainly.  But it has
>> never really gone anywhere.  Using pkg for the job would have some
>> advantages over trying to do the same thing with the old pkg_tools, but
>> would it ultimately be competitive with the way the installation media
>> works now or to freebsd-update(8)?
> 
> In never used freebsd-update between more than one version. For examble
> I never tried going from 8.0 to 9.1. I let me told that freebsd-update
> must go through each version to finally upgrade to the version we want.
> If that's true, packaging the base would avoid this behavior, make thing
> simpler for users (of course not for packaging :-) ) and surely faster.

True, true.  All pkg is, ultimately, is a tool for managing various
collections of files efficiently, and it could do that for any
collection of files you care to imagine.

	Cheers,

	Matthew

-- 
Dr Matthew J Seaman MA, D.Phil.

PGP: http://www.infracaninophile.co.uk/pgpkey
JID: matthew at infracaninophile.co.uk