From owner-freebsd-sysinstall@FreeBSD.ORG Sat Jul 10 03:07:24 2010 Return-Path: Delivered-To: sysinstall@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5C103106564A for ; Sat, 10 Jul 2010 03:07:24 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 21AA28FC16 for ; Sat, 10 Jul 2010 03:07:23 +0000 (UTC) Received: by iwn35 with SMTP id 35so3567016iwn.13 for ; Fri, 09 Jul 2010 20:07:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=fA6jCh0va6p0PL+eVm/Fld/DJ3/oOehGVtDgZ5Z2e1M=; b=lroKYRDPLSOnqd2/y9k3Omf+TG98GgkCYW3Abv1hCTOfc7OXnvKknGGX4DglvBu/Bs 8tM03+CWUGoYcQKxyL9JbBVXenuk66omPc+pX1t6aQLORK7GX17RYy3Rkb1v896NkWaV jZ1d7eMBaUAA2Rqtgc7tU3jRtGvZHx42Q/Rpw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=Sq+yurgeWVscYuHGsyni7sv/T/GJkd5CblwOC1nPFstljAwFV71a/+2hkgZ+Oebvc3 tGwDOAKkNvYhitNqamjbRe+JPfA0gWGpuaijDvRxHN56nmuXJexvITHC5+6fBR+eIWsb R0UQNzPiAN1FdyCgOg3HsdlUi7gHZgrAqEy2s= MIME-Version: 1.0 Received: by 10.231.14.194 with SMTP id h2mr10939600iba.67.1278731243359; Fri, 09 Jul 2010 20:07:23 -0700 (PDT) Received: by 10.231.214.145 with HTTP; Fri, 9 Jul 2010 20:07:23 -0700 (PDT) In-Reply-To: References: Date: Fri, 9 Jul 2010 20:07:23 -0700 Message-ID: From: Garrett Cooper To: sysinstall@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: Proposal for new `post-install userland configuration utility' X-BeenThere: freebsd-sysinstall@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Sysinstall Work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jul 2010 03:07:24 -0000 On Fri, Jul 9, 2010 at 6:20 PM, Garrett Cooper wrote: > On Fri, Jul 9, 2010 at 4:26 PM, Garrett Cooper wrote= : >> Hi all, >> =A0 =A0Randi has highly recommended several (*chuckles*) times now that = I >> develop a post-install userland configuration utility to essentially >> replace the Configure dialogs to some degree (there's some stuff in >> there that's going to go, and some things that are going to stay). >> =A0 =A0What I've let ferment for a few days is how exactly this should b= e >> done, and several concerns that I have with such a utility. >> >> Design: >> >> 1. The utility would be presented to the end-user in the motd like is >> done today with sysinstall. >> 2. The primary audience would be novice users and/or folks looking for >> an opportunity to hit the ground running ASAP with a new install. They >> would be given the option of a few simple configurations: >> =A0 =A0a. Desktop >> =A0 =A0b. Laptop >> =A0 =A0c. Server / workstation >> =A0 =A0Depending on the configuration chosen, a series of preset default= s >> would be provided (ssh on, configure an X11 greeter, etc); I realize >> that this may require adding hooks into pkg_install//libpkg (which is >> fine, because portmgr wants more visibility with libpkg eventually >> anyhow). The primary configurations could also have popular >> subconfigurations like: >> =A0 =A0i. BAMP (BSD-Apache-MySQL-PHP) (server/workstation) >> =A0 =A0ii. Gnome (desktop/laptop/workstation) >> =A0 =A0iii. KDE (desktop/laptop/workstation). >> =A0 =A0etc. This was a thought, but I was told to restrict my scope to base packages only. This could be easily extended though if others wanted to add this functionality when libpkg becomes more realized on FreeBSD. >> 3. The idea in mind would be a straightforward interface like so: >> >> i. Welcome (basic preamble about the tool and where to find more info >> the handbook) >> ii. Choose system configuration (Desktop, Laptop, Etc) >> iii. Give the user an option to customize after pressing Ok. >> iv. Fine tune configuration if user wanted to customize install (or to >> remain at the whim of the profile maintainer and/or package >> maintainers :)...). >> v. Enable Services (provide a list of popular services like what are >> available in sysinstall today, in addition to some items that aren't >> available above). >> vi. Install Dependencies via libpkg/pkg_install for third party >> configurations, if required. >> vii. Complete configuration. >> viii. Done. >> >> Each page and each bit would have a corresponding section in the >> handbook and/or manpages on how to configure the services so they >> wouldn't need to depend on the tool past the first install. >> >> I'll draw up pretty pictures later if someone wants visuals :) (Dammit >> Jim! I'm an artist, not a doctor!). >> >> The flow will be linear: you can go backwards and forwards, but no >> going back to the beginning when you partition the disk and it fails >> to contact the FTP server to download packages, and then fails to >> partition the disk on the second go-around (sorry... I couldn't >> resist...). KISS is key. >> >> Implementation: >> 1. It was suggested that it be written in C. That way I could port >> over existing code from sysinstall with minimal changes. >> 2. It would continue to use libdialog, as it would carry over code >> from sysinstall. >> 3. The code would be monolithic in the beginning, but would evolve >> over time to become more modular so that groups could predefine >> package groupings, have install scripts, and thus could custom tailor >> their installs with something similar to the fat package idea that >> Julien Lafette is working on for GSoC this year ( ;)...). >> >> Concerns: >> 1. It's written in C. >> =A0 =A0 This is a concern, because anyone running the tool on a system >> with a prebuilt configuration where I wouldn't be able to fetch all of >> the configuration data (rc.conf is nothing more than a glorified >> bourne shell script anyhow, and you can evaluate code dynamically like >> with most scripting languages with bourne shell). I'll make a single >> pass to ensure that variables aren't superficially defined, but won't >> get too fancy with the parsing (otherwise I would need to develop >> and/or hack the bourne shell parser, which wouldn't make sense :(... >> 2. It contains sysinstall-code. >> =A0 =A0- Well... any jkh code is fun to deal with, so I wouldn't expect >> anything less. >> >> Anti-bikeshed: >> >> Q: We're going to have X11 configuration code, and a bunch of other >> stuff we don't need in FreeBSD! >> A: So? We want to be a more usable OS, correct? Attracting new users >> is the big key that we need to be successful. >> >> Q: PC-sysinstall does this already, why do we need to have another >> tool to do this?! >> A: PC-sysinstall (and realistically PCBSD) only really supports a KDE >> install and configuration track and isn't really flexible to extend >> on. It's already several thousands of line of bourne shell long, and >> has established code-paths. Thus, it's not a good base for >> generalization. > > As someone else pointed out to me, yes.. pc-sysinstall is generalized. > What I was referring to was the installation distribution and the > GUI/configuration tools, which I suppose is more PCBSD centric and > developed on QT, not necessarily pc-sysinstall centric. Thanks, -Garrett