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

Pierre Schmitz pierre at archlinux.de
Sun Jun 24 19:33:26 EDT 2012


Am 25.06.2012 00:49, schrieb Dieter Plaetinck:
> On Sat, 23 Jun 2012 21:14:23 +0200
> Pierre Schmitz <pierre at archlinux.de> wrote:
>> 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.
> 
> what exactly do you mean with this? these things are already
> "decoupled" in the sense
> that they are separate projects with separate releases.  However,
> sometimes changes in one project require changes in another
> for example sometimes aif needs to be adjusted to work with archiso
> changes, the same will hold true for install-scripts
> I don't see how you can "decouple the projects" any more. (of course
> if we don't include aif on the iso, we don't need to care so much
> about updating aif after archiso changes, but I don't think that's
> what you're referring to here?)

Atm these projects at least look as they are tied together. I think we
should still keep pushing out new isos even if there is no new aif or
installer.

>> * 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.
> 
> I don't think including a broken aif per se is a bad thing, we should
> just be clear in the documentation and release announcement about its
> status,
> and be clear to our users about what we recommend and support.
> a few years ago we had the old installer on the iso + aif as
> beta/unsupported.
> If you want to attract more people to help out on archiso or
> install-scripts, that's all fine by me,
> but I doubt you'll get more help by merely not having aif on the iso.
> I would keep it on there, but mark it as outdated/unsupported as long
> as it's not properly maintained.
> 
> btw aif doesn't need much work to become non-broken, but there's not
> enough interest in it at the moment.

Depends on how broken aif is; I didn't really check that myself. If it
just has some bugs in some use cases it is perfectly fine shipping it.
If it is impossible to isntall a working system we should not put it on
the iso. But we can put it on a month later once it is fixed for
example.

But even without aif a iso release could be very useful to find and fix
bugs in archiso.

>> * 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.
> 
> big +1; this would probably simplify
> http://projects.archlinux.org/users/dieter/releng.git/ as well.
> I've never felt entirely comfortable dealing with the whole iso
> building process, precisely because it's depending on "hidden" factors
> of the host OS.
> (probably only pacman.conf but what do I know)

Good thing is we already solved some of these issues in devtools, so we
should be able to adapt those. The influences of the host system are
mostly fixed now.

>> * 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.
> 
> this is nothing new.  this has always been the idea,
> but some level of testing is *always* needed, we should never publish
> broken images.
> better to have images that are a bit older than images that have bugs
> that prevent installation on a specific architecture, installation
> medium, etc.
> a user should never have to download an iso, only to find out
> something is broken during the installation process.

Old images are quite problematic. We often require user interaction on
updates; which can be really annoying if the pile up over a year. And
more important: you might just need a new kernel to support your
hardware.

As I already said above, we should regular release new images with the
same version of the installer if there is no newer available. These
images wont need a lot of testing.

Greetings,

Pierre

-- 
Pierre Schmitz, https://pierre-schmitz.com


More information about the arch-dev-public mailing list