On Fri, 2007-09-14 at 17:21 -0500, Aaron Griffin wrote:

On 9/14/07, Tobias Powalowski wrote:

...

- gcc splitup is pending

JGC, do you know how long this will take?

I didn't have time for it tonight, so I think it will be done somewhere tomorrow. Seems there's some issues with this libgcc thing, there's multiple views on what to include. IMHO, the new gcc layout would be: - gcc-libs - gcc - gcc-fortran - gcc-java - gcc-objc gcc-libs contains all libraries that would go in a gcc build where only C and C++ are enabled, the rest of the packages would be built as gcc-java and gcc-fortran are currently built. We could splitup these things into runtime and compilers also, but especially for java I don't see need (we would have to splitup java-gcj-compat into two pieces also, which is a no-go). Another option is to make one massive gcc package that includes compilers for all these languages. Once again, there's problems with java that pulls in X. As we have fortran and java standalone packages already that work out fine, 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).

...

- 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! Also, why do we call a directory full of drivers "support"? Why not drivers or so?

On Fri, 2007-09-14 at 18:09 -0500, Aaron Griffin wrote:

On 9/14/07, Jan de Groot 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

Andy stated to have one big gcc frontend package that includes all the languages, except for java because that pulls in GTK. IMHO the above mentioned splitup is best, where each other supported language other than C and C++ will go outside core. IMHO C and C++ are the languages we should have in a core system. If we start supporting all these compilers in core, where do we stop? There's also ada that we can package, there's also mono to compile .Net, and there's also mono-basic to compile visual basic ;)

...

...

...

- 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.

Looking at glib2, it's 5.1MB installed size. That includes both static and shared libs. 1.3MB of that is static libs that we add to it to make sure that syslog-ng can compile static. Is it really so hard to have a library with a G in the name on a base system? Other option is to take a version of syslog-ng that didn't depend on glib2. Compiling glib2 static into syslog-ng will also make the binary bigger, so the savings of not having glib2 on your system is actually even smaller than the 3.8MB that would be "lost" when installing glib2 with only dynamic libs.

2007/9/15, Aaron Griffin :

On 9/14/07, Jan de Groot wrote:

...

Looking at glib2, it's 5.1MB installed size. That includes both static and shared libs. 1.3MB of that is static libs that we add to it to make sure that syslog-ng can compile static. Is it really so hard to have a library with a G in the name on a base system? Other option is to take a version of syslog-ng that didn't depend on glib2. Compiling glib2 static into syslog-ng will also make the binary bigger, so the savings of not having glib2 on your system is actually even smaller than the 3.8MB that would be "lost" when installing glib2 with only dynamic libs.

Hey, I'm fine with having glib2 in core. It's a decent library after all.

I'm all for the simplest solution to this, because it's really a minor issue in the grand scheme. To me, it looks like the simplest solution is to just include it in the repo. It's not a huge deal, it IS only a makedepend anyway.

IMO we *can* have makedepends in any other binary repo, it does not break anything. Moving makedepends to the same repo brings nothing useful IMO. -- Roman Kyrylych (Роман Кирилич)

Am Samstag, 15. September 2007 10:58:15 schrieb Tobias Powalowski:

...

IMO we *can* have makedepends in any other binary repo, it does not break anything. Moving makedepends to the same repo brings nothing useful IMO.

well it breaks makerworld if you do so. greetings tpowa

And it would make the whole splitting a bit useless. So lets keep it clean. -- archlinux.de

Hi cvs moving finished. now we are waiting for the db-scripts and mysql entries. anyone with enough rights and knowledge now it's your turn :) greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org