Date: Wed, 20 Apr 2016 10:53:02 -0400 From: Paul Mather <paul@gromit.dlib.vt.edu> To: freebsd-current@freebsd.org Subject: Re: [CFT] packaging the base system with pkg(8) Message-ID: <0C8A7C64-8D7C-4B2D-9387-294FBF049941@gromit.dlib.vt.edu> In-Reply-To: <mailman.1222.1461151175.46920.freebsd-current@freebsd.org> References: <mailman.1222.1461151175.46920.freebsd-current@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> Message: 20 > Date: Wed, 20 Apr 2016 12:48:06 +0300 > From: Slawa Olhovchenkov <slw@zxy.spb.ru> > To: Dan Partelly <dan_partelly@rdsor.ro> > Cc: David Chisnall <theraven@FreeBSD.org>, Julian Elischer > <julian@FreeBSD.org>, Nathan Whitehorn <nwhitehorn@freebsd.org>, > freebsd-current@freebsd.org > Subject: Re: [CFT] packaging the base system with pkg(8) > Message-ID: <20160420094806.GJ6614@zxy.spb.ru> > Content-Type: text/plain; charset=3Dutf-8 >=20 > On Wed, Apr 20, 2016 at 12:00:36PM +0300, Dan Partelly wrote: >=20 >> 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. >=20 > 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? >=20 > How name system, updated all w/o compiler? or only some services? > Currently we have simple naming: >=20 > 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.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0C8A7C64-8D7C-4B2D-9387-294FBF049941>