On Mon, Apr 18, 2016 at 10:30:48PM +0200, Rainer Duffner wrote:

> > Am 18.04.2016 um 22:07 schrieb Lev Serebryakov <l...@freebsd.org>:
> > 
> > On 18.04.2016 22:40, Glen Barber wrote:
> > 
> >> 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.
> > 
> > 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.
> > 
> >  It seems that it is ideological ("holy war") discussion more than
> > technical one...
> From the discussion, I believe it’s primarily driven by the need/desire to 
> have small packages to make updates easier on the mirror-servers.
> I’m 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.

Lesser of files is best. 800 packages is better then 14k. 10 packages
is better then 800.

> freebsd-update is „only" unreliable if
>  - you go through a proxy with authentication
>  - that proxy doesn’t do http-pipelining (or does it bad/is broken is this 
> respect) (certain version of Sophos UTM for example…)

freebsd-update broken on server side.
freebsd-update not relaible on client side.
freebsd-update to long even on SSD and 10Gbit connectivity.
freebsd-update to long to prepare (4x times longer of one compiling)

> As for the packages: I wouldn’t mind „fatter“ packages. I’d mirror them 
> locally anyway (I hope this is possible - AFAIK, the freebsd-update files are 
> not supposed to be mirrored), and I don’t have a thousand servers to pull 
> them down all at once anyway (working on that ;-)).
> I’m 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.

Hundred of millions iPad and iPhones got update in near-gigabyte chunks.

> 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’m 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’t list them.
> And that pkg upgrade doesn’t upgrade base-packages.
> _______________________________________________
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to