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

On Wed, Apr 20, 2016 at 10:43:08AM -0400, Paul Mather wrote:

> 
> > 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.

Identification of custom builds is another problem and now we do this
by contens of src.conf, make.conf options and kernel config file.
This is enough and I am don't see necessity for change.

> 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.

With CVS we use timestamp (as for csup).

> 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.

How identify this systems? By 800-line lists of package versions?

> 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.

Some /etc/src.conf settings is compile-time options and can't be done
by packages. Kerberos, for example.