Date: Mon, 18 Apr 2016 22:30:48 +0200 From: Rainer Duffner <rainer@ultra-secure.de> To: lev@FreeBSD.org Cc: freebsd-current Current <freebsd-current@freebsd.org> Subject: Re: [CFT] packaging the base system with pkg(8) Message-ID: <2D6C2427-806C-4F18-8B1C-263CCC34CF21@ultra-secure.de> In-Reply-To: <57153E80.4080800@FreeBSD.org> References: <20160302235429.GD75641@FreeBSD.org> <57152CE5.5050500@FreeBSD.org> <9D4B9C8B-41D7-42BC-B436-D23EFFF60261@ixsystems.com> <20160418191425.GW1554@FreeBSD.org> <571533B8.6090109@freebsd.org> <20160418194010.GX1554@FreeBSD.org> <57153E80.4080800@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> Am 18.04.2016 um 22:07 schrieb Lev Serebryakov <lev@FreeBSD.org>:
>=20
> On 18.04.2016 22:40, Glen Barber wrote:
>=20
>> This granularity allows easy removal of things that may not be wanted
>> (such as *-debug*, *-profile*, etc.) on systems with little storage. =
On
>> one of my testing systems, I removed the tests packages and all debug
>> and profiling, and the number of base system packages is 383.
> IMHO, granularity like "all base debug", "all base profile" is enough
> for this. Really, I hardly could imagine why I will need only 1 debug =
or
> profile package, say, for csh. On resource-constrained systems NanoBSD
> is much better anyway (for example, my typical NanoBSD installation is
> 37MB base system, 12MB /boot and 10 packages), and on developer system
> where you need profiled libraries it is Ok to install all of them and
> don't think about 100 packages for them.
>=20
> Idea of "Roles" from old FreeBSD installers looks much better. Again,
> here are some "contrib" software which have one-to-one replacements in
> ports, like sendmail, ssh/sshd, ntpd, but split all other
> FreeBSD-specific code? Yes, debug. Yes, profile. Yes, static =
libraries.
> Yes, lib32 on 64 bit system.
>=20
> It seems that it is ideological ("holy war") discussion more than
> technical one...
=46rom the discussion, I believe it=E2=80=99s primarily driven by the =
need/desire to have small packages to make updates easier on the =
mirror-servers.
I=E2=80=99m really not sure (yet), which is worse: the current system =
that pulls down some 14k small files for a system-upgrade - or a system =
where the base-system is split into almost 800 packages.
freebsd-update is =E2=80=9Eonly" unreliable if
- you go through a proxy with authentication
- that proxy doesn=E2=80=99t do http-pipelining (or does it bad/is =
broken is this respect) (certain version of Sophos UTM for example=E2=80=A6=
)
AFAIK.
As for the packages: I wouldn=E2=80=99t mind =E2=80=9Efatter=E2=80=9C =
packages. I=E2=80=99d mirror them locally anyway (I hope this is =
possible - AFAIK, the freebsd-update files are not supposed to be =
mirrored), and I don=E2=80=99t have a thousand servers to pull them down =
all at once anyway (working on that ;-)).
I=E2=80=99m pretty sure the impact on the current FreeBSD delivery =
infrastructure would be quite substantial, if updates came in 60MB =
chunks - esp. if there was some sort of auto-update mechanism in place.
Fast-forward to the future where a lot (millions?) more embedded devices =
are based on FreeBSD and pull updates from the FreeBSD infrastructure.
Or if the container hype-train reached FreeBSD and people started to =
containerize everything, resulting in even more base-package update =
downloads.
So, I can see both sides. Neither I=E2=80=99m really satisfied with.
I hope a way is found to manage these number of packages without losing =
sanity and that a normal pkg info doesn=E2=80=99t list them.
And that pkg upgrade doesn=E2=80=99t upgrade base-packages.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2D6C2427-806C-4F18-8B1C-263CCC34CF21>