On 9/14/07, Jan de Groot <jan@jgc.homeip.net> wrote:
I would prefer to have the splitup as layed out above: C/C++ in one compiler package, C/C++ runtime libs in one package and one package for each language we support (objc moves to a standalone pkg).
I like this too. We don't really want to go too crazy with splitting things whenever possible. I mean, it's nice an all, but there's a fine line where things become a pain to maintain simply because we wanted to save one or two deps and a few hundred K of disk. But I trust you know what you're doing here. I'll throw my weight behind the list you had above: - gcc-libs - gcc - gcc-fortran - gcc-java - gcc-objc
- syslogng needs to be reviewed
eliott brought up a worthwhile point. While it might be ugly, what's wrong with throwing glib into the 'devel' category?
glib2 is not devel, it's a lib!
Ack yeah. I meant, really "why not move glib2 to core?" - the exact category is bikeshed-y, I just didn't want to go all overboard with how we split up core. How does everyone else feel on splitting off all the libs into a "lib" category. Personally, it feels a tad artificial to me, because the other stuff is split into *usage* based categories ("this is a base system, these are support files") and not really *what* the packages are ("these are network related, these are modules, these are text utils"). But still, I'd like some more opinions here.
Also, why do we call a directory full of drivers "support"? Why not drivers or so?
This was explained by brain0 - but again, the naming is really superfluous, and doesn't matter that much. As a side note though, it's not all drivers. As Thomas explained it, it is all the stuff that is needed to go from "ok installed" to "pacman -Syu" - most likely all network stuff, but I could foresee other things too. Andy suggested the name "essential".