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

> Message: 20
> Date: Wed, 20 Apr 2016 12:48:06 +0300
> From: Slawa Olhovchenkov <slw_at_zxy.spb.ru>
> To: Dan Partelly <dan_partelly_at_rdsor.ro>
> Cc: David Chisnall <theraven_at_FreeBSD.org>, Julian Elischer
> 	<julian_at_FreeBSD.org>, Nathan Whitehorn <nwhitehorn_at_freebsd.org>,
> 	freebsd-current_at_freebsd.org
> Subject: Re: [CFT] packaging the base system with pkg(8)
> Message-ID: <20160420094806.GJ6614_at_zxy.spb.ru>
> Content-Type: text/plain; charset=utf-8
> 
> On Wed, Apr 20, 2016 at 12:00:36PM +0300, Dan Partelly wrote:
> 
>> IMO,  the number of packages per-se is not a problem as long as you
>> can manage them without arcane commands, aliases, pipe - filters,
>> or scripts. (they all have their place, but less , the better)  My
>> point is that I don't really want to keep on my head a Unix hacker
>> hat. I (and presumably many other humans ) like simple things,which
>> allow me to type a short command (preferably the whole system should
>> be simple enough to be explained in one-two pages in handbook) ,
>> wait for completion, and get on with my life.
> 
> Yes and no.
> 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.

Superficially, it does, but in reality it doesn't.  I can grab the source for 10.3-RELEASE and then add a lot of WITH_* and WITHOUT_* settings in /etc/src.conf and build a kernel and world and end up with a system that is missing a lot of functionality that is ordinarily present with an empty /etc/src.conf.  That missing functionality could be the reason for a problem I am having with my "10.3-RELEASE" system.

That is the reality of FreeBSD *now* and I still am able to get help on FreeBSD mailing lists when I have problems.

The case of a moving target is truer of those who choose to run -STABLE or -CURRENT.  If I say I'm running 10.3-STABLE three months from now, what version of the code base am I actually running?  Sure, now we have the SVN revision number to help pinpoint the version of the code being run (setting aside the effects of /etc/src.conf), but back in the days when FreeBSD was in CVS we didn't have that nicety and yet people were still able to get help with problems running -STABLE or -CURRENT on the mailing lists.

A packaged base is just another way of describing the state of the system.  People on mailing lists will still be able to help people fix their problems, but they'll just use different information to pinpoint the precise components affected.

Arguably, a packaged base will make it easier to help people, because it makes more explicit the dependencies of different parts of the system.  It's been my experience that the interactions and impact of the various /etc/src.conf settings are not entirely well known, at least to end-users.

Cheers,

Paul.