Hi, On Mon, Jan 09, 2006 at 22:37:40 -0600, Matt Housh wrote:
On Mon, 2006-01-09 at 22:44 +0100, Johannes Winkelmann wrote: [...]
- bash 3.1 has serious bugs, and can easily be updated later
What kind of bugs? Serious enough that installing it by default would be a bad idea (tm)? Okay, upon further examination the only grave problem seems to be this one: http://lists.gnu.org/archive/html/bug-bash/2005-12/msg00041.html
There's a number of patches against 3.1, available from the official gnu bash download server, including a fix for the bug mentioned above: http://ftp.gnu.org/gnu/bash/bash-3.1-patches/ However, there was not 3.2 or 3.1.1 release to address those; as Simone mentions, it's probably worth updating to it later once there's a bugfix release from the bash crowd.
There's one important question we have to answer: do we want to move x11/firefox/gtk back to opt? As mentioned in the previous thread about this, I'd prefer to move them back, and so is Simone.
I honestly don't care either way. Do you want to keep them on the iso even so? I thought the consensus at cruxcon was that core == iso. If we don't want them on the iso I can understand that but let's be consistent. We'd include "Per's selection" on the ISO, that is, firefox, gtk, windowmaker etc.
I remember the decision we had regarding "core ports are those that go with the ISO", but I consider it somewhat flawed now: if you look at the ports tree, I don't see any valid argument to declare window maker core but not the other WMs, or gtk but not qt3. Sure, they're on the ISO, but does that matter once you installed the system? If you do a server installation, why should X11 be in the "core" collection? Those questions were what changed my mind (Simone's arguments helped, too;-)). I think we're trading in some comfort for us the creators of the ISO (since we'll have to slightly modify the Makefile to list the packages that are included on the ISO), but get a more meaningful collection name in the ports tree. At the same time, the adjusted Makefile will make it easier to build customized ISO's without rearranging your ports tree. Finally, as discussed in the dependency thread, "core" will imply that you need those ports to get a system which init(8)s fine. Otherwise, we'd be in a "oh you can remove some ports from core, but not all" situation. I hope this makes any sense :-). Best regards, Johannes -- Johannes Winkelmann mailto:jw@tks6.net Bern, Switzerland http://jw.tks6.net