Mail archive
alpine-devel

Re: [alpine-devel] apk package rollback feature?

From: V.Krishn <vkrishn4_at_gmail.com>
Date: Mon, 2 Feb 2015 18:05:00 +0530

> On Thu, 22 Jan 2015 09:49:36 -0800
>
> Thomas Zelch <thomaszelch_at_gmail.com> wrote:
> > Hi,
> >
> > Yesterday i ran into an issue with the linux-grsec package.
>
> Which version was it?
>
> > I searched the wiki and help output of apk, but couldn't find a way to
> > downgrade the package comfortably.
> > I ended up taking an older version of the package from an older iso file
> > that i still had in my downloads folder.
> >
> > Is there a more comfortable way implemented?
> > If not, what does everybody think about it?
> > I think it would be a great addition.
>
> I think so too but there are no easy way to solve it. Partially because
> there are different ways to run alpine. for example, if you run a
> diskless (aka tmpfs) install, the boot media will not be in a package.
> Instead it will be a kernel and modloop squashfs image on boot media.
> We now have an experimental update-kernel which could have support for
> this.

I am not sure how in diskless-mode the kernel+modloop squashfs image would be
effectively updated, does this not require rebooting ??
If it does not I can think over it !

>
> For traditional disk installs, we would need keep old versions of
> packages. I think this is ok-ish for stable release branches but not
> for edge as it would mean we would keep every package ever built.

Suggestion for updates (for every pointy git tag in stable version),
http://nl.alpinelinux.org/alpine/v3.1/updates/1
i.e <base version>/updates/<updatevernum>
then, Add logic to process http://nl.alpinelinux.org/alpine/v3.1/updates
directory in `apk` application (reason, this would save one to add extra line
in /etc/apk/repositories).

>
> Alternatively we would need create new package for each kernel version,
> so you could have multiple kernel packages installed in parallel. I
> don't know if we want that either.
>
> Other options would be to do LVM snapshots before upgrade and do
> rollback of that in case emergency. That would be kinda nice because it
> would make the upgrade/rollback atomic. that would not work with the
> kernel itself though because /boot on LVM is not supported...
>
> I am open to other ideas how to properly implement a kernel rollback
> feature.

With above pkgs method implemented, there can be,

`apk tag=test123`
  "This will capture the current state of /etc/apk/world with versions of pkgs
installed"
`apk update`
`apk upgrade` ALT-METHOD `apk upgrade tag=test123`
  "ahh this not a good upgrade !! what to do !!"
`apk rollback=test123`

  "Voila!!"
(but still open to issues it may create)

Regards.
V.Krishn


---
Unsubscribe:  alpine-devel+unsubscribe_at_lists.alpinelinux.org
Help:         alpine-devel+help_at_lists.alpinelinux.org
---
Received on Mon Feb 02 2015 - 18:05:00 UTC