[arch-releng] using mkinitcpio-git in releng env

[Dieter Plaetinck]

On Thu, 24 Nov 2011 10:41:59 +0100
Thomas Bächler <thomas at archlinux.org> wrote:

> Am 24.11.2011 10:24, schrieb Dieter Plaetinck:
> > On Wed, 23 Nov 2011 23:52:53 +0100
> > Thomas Bächler <thomas at archlinux.org> wrote:
> > 
> >> We could install mkinitcpio-git in the releng environments. Dieter?
> > 
> > This is technically very possible, of course.
> > OTOH that seems messy:
> > the goal of the releng environment is to build isos based on
> > stable/known packages. testing isos which can turn into stable isos
> > after testing. (stable isos definitely need to be built from
> > packages) archiso is the exception because it's only used for iso
> > building anyway. and sometimes i enable testing packages and then
> > disable it again, to test specific packages. but git packages are a
> > step further (too far imho)
> > 
> > I would like to keep a clean env to build "testing->stable" images, 
> > is using testing packages not enough? or can't you locally build
> > isos with mkinitcpio from git? if "no and no", i would rather setup
> > a 2nd env rather then "unstabilizing" the current one.
> 
> The packages that are installed on the ISO are standard core packages
> regardless. This is only about the mkinitcpio version used to build
> the image. If we want to test new features now, but mkinitcpio
> releases take too long, this is the only way. This is not about
> destabilizing, this is about fixing bugs that prevent us from moving
> the archiso development ahead.
> 
> The 'mkinitcpio' package is only used for building archiso's
> initramfs, so there is no way to do harm, other than having a broken
> test ISO.
> 

mkinitcpio is also used to build users' initramfs and users' isos.
You may say "there is no way to do harm, other than having a broken test ISO.",
but I find that hard to believe, IMHO this would open the gate for subtle bugs in our isos
which may not be known because we used a newer version then what's in the testing repository, for example.
Having an opening for sneaky bugs is not good for isos that get promoted to official media,
unless by the time we promote isos, the changes that were in git ended up in stable mkinitcpio packages,
or if we can switch back and forth between mkinitcpio-git and the packaged one.

personally, i think the cleanest solution is just to have 2 environments. one with only stable packages
(and archiso-git), and another one with archiso-git, mkinitcpio-git and whatever else from git.

Dieter