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

From: Thomas Zelch <[email-masked]>
Date: Thu, 22 Jan 2015 09:49:36 -0800

Hi,

Yesterday i ran into an issue with the linux-grsec package.
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.

Regards,
Thomas

---

From: Orion <[email-masked]>
Date: Thu, 22 Jan 2015 14:24:39 -0800

On Thu, 22 Jan 2015 09:49:36 -0800
Thomas Zelch <[email-masked]> wrote:

> ...

I think this feature would be a nice feature to have for Alpine.

This said, I would prefer to develop a port/redesign of the Nix package
manager written in a safe systems language like go lang. I am currently
working on this. I think it's possible to make design it such you
could have the full complexity and features that nix provides but also
build it modular such that a subset of the tools could provide
equivalent simplicity, features, and build size.

-- 
keybase.io/systmkor

---
Unsubscribe:  [email-masked]
Help:         [email-masked]
---

---

From: Natanael Copa <[email-masked]>
Date: Thu, 29 Jan 2015 12:02:27 +0100

> Yesterday i ran into an issue with the linux-grsec package.

Which version was 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.

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.

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.

---

---

From: "V.Krishn" <[email-masked]>
Date: Mon, 2 Feb 2015 18:05:00 +0530

> We now have an experimental update-kernel which could have support for

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 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).

> I am open to other ideas how to properly implement a kernel rollback

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

---