On 2016-04-18 8:17 PM, Alfred Perlstein wrote:
Can someone on the "too many packages" campaign here explain to me how
having too fine a granularity stops you from making macro packages
containing packages?
Because honestly I can't see how having granularity hurts at all when if
someone wanted to make it less granular all they would have to do is
make some meta-packages.
It's the *I have to put it back together* part that's annoying. I
didn't break something that has worked, forever. It shouldn't be
incumbent on me to un-break someone else's work.
Now if the system ships with each-file-in-a-package, fine. Just give me
gross subsets that make my life as a sysadmin liveable. E.g., base
POSIX functionality should be a 'group' package. And I would hope, the
default installation package. I would go for the argument that, e.g.,
the dev stuff (cc, yacc, lex) could be split off, but at least include
the headers that match what's in /lib and /usr/lib, in a compiler
agnostic set. Since the point of packages is to allow for selections of
optional software.
--lyndon
_______________________________________________
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"
