Nathan Whitehorn wrote:
Thanks, Roger. That seems perfectly reasonable. I'm not sure that goal is really met by having 800 packages, though, or at least I see no particular gain relative to a handful (where things like OpenSSL or sendmail would be discrete things). (Almost) every single individual library in the base system is right now its own single-file package, which is what I am objecting to.

Hey Nathan.  I admit to not having looked at it with the goal of
consolidation.  Presumably there will be libs that can be grouped but we
should look at each consolidation's pros and cons.  Baptiste's rational
is the policy we have and, IMO, refinement should start at that (policy)
level.  The process has no doubt accelerated thanks this thread but
aside from debug, profile and a few others it's not clear if there are
grouping policies that would significantly bridge the gap between our
respective goals.

It's critical that we look at other distribution's package systems.  My
count packages on Linux and monolithinc-base FreeBSD desktops is about
2,500 and 700 respectively.  Adding 383 base packages (assuming no debug
or profile) would push this 28% ratio to 43% of Linux' package count.
Of course servers will be different and our FreeBSD package counts would
rise from the low to mid 100s to over 600 which is still only 60-70% of
the packages on Linux servers I have access to.  Having managed Linux
systems with 1000 to 3000 packages I can't say that I have real concerns
for pkgng in this regard.  The package management tools have to scale of
course but on a KIS scale more packages = less time spent for a given
level of functionality and security (in my experience).

I hope we can look forward to some top-level policy suggestions to
further refine the base package schema.

_______________________________________________ mailing list
To unsubscribe, send any mail to ""

Reply via email to