Date: Thu, 13 Jan 2011 22:59:33 +0000
From: Natanael Copa <ncopa@alpinelinux.org>
To: William Pitcock <nenolod@dereferenced.org>
Cc: alpine-devel@lists.alpinelinux.org
Subject: Re: [alpine-devel] the setup-alpine and setup-disk scripts
Message-ID: <20110113225933.3def039f@alpinelinux.org>
In-Reply-To: <20110113125610.14cf1b47@petrie.gateway.2wire.net>
References: <20110113170513.3c34bd8b@ncopa-desktop.nor.wtbts.net>
	<20110113125610.14cf1b47@petrie.gateway.2wire.net>
Precedence: list
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Thu, 13 Jan 2011 12:56:10 -0600
William Pitcock <nenolod@dereferenced.org> wrote:

...

> > So, I'm thinking, append setup-apkrepos to setup-alpine so user
> > gets a http repo. User should only need to press enter to get a
> > sane default. We maybe dont even need to ask user but can just set
> > it. I was thinking maybe having the mirror list in a package? Or we
> > download frrom net? With a package we dont need have the network
> > running when we configure the http repo.
> 
> Having a mirror list in a package would be good, however, we would
> either want to have it prompt for a mirror *out* of the package list
> or rework repository selection in APK.
> 
> I think the way ArchLinux/Pacman handle this is subpar.  I think
> prompting is better.

I didn't really understand what you said. You mean we have the
mirror list in a package, and then you get the list presented and user
picks one of them? Then we keep that list up-to-date with normal apk
updates.

I'm thinking apkbuild could be something like:

pkgname="alpine-mirrors"
pkgver="$_date"
source="http://www.alpinelinux.org/alpine/MIRRORS.txt"
...
package() {
	install -D "$srcdir"/MIRRORS.txt \
		"$pkgdir"/usr/share/alpine-mirrors/MIRRORS.txt
}

...
 
> > (Currently there are some "xen support" in there, which enables grub
> > instead of extlinux. I'd like to rip that out, or re-implement that
> > as a grub support instead of a xen support.)
> 
> The current xen packaging does not even use this stuff.  

Ok. I think I rip it out again then.

> The way I
> intend to do this is by using extlinux's mboot.c32, with something
> along the lines of:
> 
> label xen
>    kernel /boot/mboot.c32
>    append /boot/xen-4.gz dom0_mem=512M --- /boot/vmlinuz-xen0 root=...
>           --- /boot/initramfs-xen0
> 
> That append line is ugly and it's a one-liner.  What we *really* need
> is a script that can build extlinux.cfg based on what it finds.  That
> way we could support keeping old kernels around for the event of
> regressions.

scripts that builds ... based on what it finds. Thats what I've been
trying to do with the setup-disk. And yeah, we should split it up in a
separate setup-extlinux (or setup-bootloader)

 
> > Would also be nice if the setup scripts could be fed with a preseeed
> > config file where the questions already was answered, so you could
> > to unattended installs.
> 
> I've been kind of thinking about this, and I think honestly we might
> be better off writing an installation framework in C like
> debian-installer. 

In C?

> Actually, I really got down to thinking about it
> last night and I came to the conclusion that a CLI frontend to ACF may
> be actually what we want, which would actually I suppose be the exact
> same thing as debian-installer (d-i is basically an app called
> 'cdebconf' going over some specific debconf components; the new
> installer could work the same way going over specific ACF
> components!).

oh yes... ACF. forgot that.

> The benefit to *that* is, if we can make a CLI interface to ACF (and
> we *should* be able to because it's MVC) then we can also make a GTK+
> interface to ACF and have a graphical installer for running from a
> desktop livecd variant of Alpine similar to what Fedora and Ubuntu
> have going on.

Yes! ACF is the way to go. I think there already are some cli interface
to some of the components.

Good thinking!

Btw, i wrote lua bindings to openrc and augeas with ACF in thought.

> Lua is pretty cheap really.  We might not even have to do C, if we can
> get something like parted bindings for Lua.

Yes. Actually, lua bindings for parted and for lvm. Shouldnt bee too
hard. Anaconda (fedora/redhat) is python I think. Same with suse's yast.

> I think the hybrid option is a good option for some users.

After some more thinking, we want probably want present 2 modes instead
of 3:
1. tmpfs (default)
2. native disk

If tmpfs then ask for lbu media and optional datadisk(s) for swap
and/or data. (/home /var etc).

-nc


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---