[arch-dev-public] New install iso - proof of concept

[Tom Gundersen]

On Sat, Jun 23, 2012 at 9:14 PM, Pierre Schmitz <pierre at archlinux.de> wrote:
> it being discussed o IRC for some time now but I guess it's a good idea
> to sum our current progress up. I'll also add a few suggestions about
> how we might improve our iso releases.
>
> I created a testing iso which can be found at:
> http://pkgbuild.com/~pierre/ Besides the patches I had sent to the
> releng list it includes pacman-key from Allans working repo and Dave's
> arch-install-scripts. In addition to an updated set of packages another
> noticeable change is that signature verification is now supported and
> works out of the box. The keyring is initialized on boot and so you can
> install new packages within the live system as well.

Nice stuff. I have been testing Dave's arch-install-scripts and used
it for my latest install. Very convenient stuff, so having this on an
install medium would be great.

> Overall I would suggest this:
> * Decouple aif, install-scripts, archiso and actuall iso releases. This
> means have tags for those and provide packages in our repos.

+1. I agree that this would speed up development, and hopefully also
lower the bar for contributing.

> * It's not a bad thing to start off with an iso that does not include
> aif a first. This should actually speed up development and hopefully get
> us more help from the community.

+1. Creating iso's with aif before it is ready will not do much good.
Provided that it is easy to "roll your own iso" it should still be
easy for people to test out the aif and contribute to it.

> * archiso should be changed in a way that would allow anyone to easily
> create official isos with one command. It should result in the same iso
> no matter how the host is configured.

This sounds very useful.

> * We should treat the iso more like our other package and not aim for
> the most perfect product. Instead let's release new isos regularly; e.g.
> every month.

Absolutely. iso's should be pushed out very frequently. We don't want
to worry about the most recent iso having bugs that have been fixed in
the repos, and (in case of core iso's, which I oppose anyway) we don't
want any user interaction to be required on the first update after
install (i.e. we should push a new iso whenever user interaction is
required).

-t