[arch-dev-public] [core] progress
Hi ok guys sum up what already done: [core] cvs partially setup ok base is moved in and divided into the categories according to this: https://www.archlinux.org/wiki/Core-Repository/ - packages from extra is still missing though - gcc splitup is pending - syslogng needs to be reviewed - the move to of the rest of current to cvs-extra2 is not done im tired now and going to bed, i'll continue on it tomorrow morning. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org
On 9/14/07, Tobias Powalowski <t.powa@gmx.de> wrote:
- gcc splitup is pending
JGC, do you know how long this will take?
- 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?
- the move to of the rest of current to cvs-extra2 is not done
I will copy this for ya soon!
im tired now and going to bed, i'll continue on it tomorrow morning.
Thanks tpowa!
On Fri, 2007-09-14 at 17:21 -0500, Aaron Griffin wrote:
On 9/14/07, Tobias Powalowski <t.powa@gmx.de> 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 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".
On Fri, 2007-09-14 at 18:09 -0500, Aaron Griffin wrote:
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
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.
On 9/14/07, Jan de Groot <jan@jgc.homeip.net> 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.
2007/9/15, Aaron Griffin <aaronmgriffin@gmail.com>:
On 9/14/07, Jan de Groot <jan@jgc.homeip.net> 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 (Роман Кирилич)
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 -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org
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
2007/9/15, Tobias Powalowski <t.powa@gmx.de>:
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.
Hmm, then makeworld should be fixed to support fetching makedepends from other repos. :-P Well, probably that's just me that finds "makedepends should be in the same repo" a limiting thing... So nevermind. -- Roman Kyrylych (Роман Кирилич)
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
/arch/db-core and /arch/db-core64 are there now, and the web stuff should be set up to receive packages. Thanks Xentac for your help with that.
participants (6)
-
Aaron Griffin
-
Jan de Groot
-
Pierre Schmitz
-
Roman Kyrylych
-
Thomas Bächler
-
Tobias Powalowski