Subject: Re: [alpine-devel] the setup-alpine and setup-disk scripts

From: Natanael Copa <[email-masked]>
Date: Thu, 13 Jan 2011 22:59:33 +0000

On Thu, 13 Jan 2011 12:56:10 -0600
William Pitcock <[email-masked]> 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:  [email-masked]
Help:         [email-masked]
---

---

From: "Matt Smith" <[email-masked]>
Date: Fri, 14 Jan 2011 05:10:38 -0600 (CST)

On Thursday, January 13, 2011 4:59pm,
> 		"$pkgdir"/usr/share/alpine-mirrors/MIRRORS.txt

I think that's an excellent idea.

With the work I've done to setup-apkrepos and these new ideas you've all
come up with, I sat down and came up with some notes on how to improve on
this:

- make `setup-apkrepos` use MIRRORS.txt from APK
- Ask user if they want to..
  1. Automatically pick random mirror (Default)
  2. Automatically pick mirror based on speed (must be connected)
  3. Manually pick mirror from list
     - List mirrors, their locations, and maybe even their provider/sponsor
  4. Manually enter a URL or local path
- Finally, ask the user if they want to run 'apk update', warning that
  they must be connected in order to use Internet repositories.
  (Default to 'Yes'?)

Regarding mirror locations, I'm thinking we should make MIRRORS.txt more
of a flat-file database with a single-character delimiter - perhaps the
pipe character (|).

It could look something like this:

http://distrib-coffee.ipsl.jussieu.fr/pub/linux/alpine/alpine/|Paris, FR
http://nl.alpinelinux.org/alpine/|Schiphol-Rijk, NL
http://dl-4.alpinelinux.org/alpine/|California, US
http://dl-3.alpinelinux.org/alpine/|Colorado, US
http://dl-2.alpinelinux.org/alpine/|New York, US

What do you think?

Matt

---