Here I'm republishing an old blog post of mine originally from January 2014. The article has been slightly improved.

First public Arch:E5 repository published

The first public Arch:E5 repository is available now! If you have no idea what _E5_ is, you may want to take a look at the post "Announcing Arch:E5!" first.

Announcing Arch:E5!

About one month passed and I just made the __skel__ (or "skeleton") repository available. It can be used to pacstrap a fairly minimal Arch:E5 installation. I'll describe how to do that in a minute, but first a few words about what this actually is.

Arch:E5 structure

Arch uses a rather simple repository layout: The most important packages are in core and everything else is in extra. Packages not officially maintained by the project can probably be found in community. Disregarding a few special things this is already it.

E5 booted using runit/ignite (PNG)

While a "base" install of Arch is quite small compared to most well-known distros, it still pulls in quite a few things you might not want to have. Right, you can easily uninstall packages later. Or you could do without the "pacstrap" script and make use of pacman's group feature. But using pacstrap is simply a very convenient way of installing Arch.

Now the idea is to allow for an installation that can be customized even more than Arch's right from the beginning and thus split _core_ into two repositories: _skel_ and _default_. The former consists of everything absolutely necessary to get an Arch-based system up and running while the later holds the default packages that make the system actually useful.

The skeleton repository

Why would one do that split? Well, imagine you have a very specific idea of what your system should be. Perhaps you are an _vi_ user. For what reason should _nano_ even be installed at all? Or you don't intend on using _systemd_. Why have it forced on you in the first place?

Just pacstrapping the skeleton of your system together with what you actually want is a pretty obvious and comfortable solution.

E5 brings back one of the strong points of the classical Arch: rc.conf! (PNG)

Right now skel contains all the packages which are in the "mini" group - 59 packages to be precise. I intend to put some more work into it to break it down to 50 packages at most (or rather: as few as possible). Some packages like the bootloader (_syslinux_) or the init-system (_runit_) are likely to be moved to repository default in the future when E5 begins to offer alternative choices. Decreasing the number of packages could also be done by replacing some of them with others that have fewer dependencies.

How to install?

__Warning:__ This ist just a __preview__. The system you'll end up with is not of much use on its own at this time!

If you want anything more than the bare skeleton, pacstrap it on top of E5 (from the Arch repositories) after the initial pacstrap is complete!

Preparing to pacstrap an Arch:e5 skeleton installation (PNG)

As you can see, installing Arch:E5 is rather simple. Just boot from an Arch Linux live medium and make some changes to the _/etc/pacman.conf_ file.

1) Comment out any Arch Linux repositories

2) Then add the following:

[e5-skel]
SigLevel = Never
Server = http://www.elderlinux.org/repos/e5-skel

3) Once you saved the changes, you can check if pacman can read the package database using _pacman -Sy_. This is optional, of course, since the pacstrap script updates the db anyways.

4) Proceed with a more or less typical Arch installation:

https://wiki.archlinux.org/index.php/Installation_Guide

Create and format your partitions, mount them and finally pacstrap the group _mini_ instead of _base_. Then use _genfstab_ and reboot. That's it. If you follow the default partition layout, there's no need to chroot to the environment since syslinux is installed automatically.

What’s next?

I'll definitely continue working on E5. My next goal is currently to prepare and publish the default repository.

Content of "skel"

Since there's not much in it, here's the complete list of packages which skel currently holds (all but 3 packages were actually built with clang 3.4, btw.):

BACK TO 2014 OVERVIEW