From: "V.Krishn" <vkrishn4@gmail.com>
Reply-To: vkrishn4@gmail.com
To: Natanael Copa <ncopa@alpinelinux.org>
Subject: Re: [alpine-devel] apk package rollback feature?
Date: Mon, 2 Feb 2015 18:05:00 +0530
User-Agent: KMail/1.13.7 (Linux/3.9.6-64; KDE/4.8.4; x86_64; ; )
References: <CABKXMoYgQtML+BV4EaYZqonvyyDdLWPaBfpQU_a5DLTERA0+Pw@mail.gmail.com> <20150129120227.2d69bb49@ncopa-desktop.alpinelinux.org>
In-Reply-To: <20150129120227.2d69bb49@ncopa-desktop.alpinelinux.org>
Cc: alpine-devel@lists.alpinelinux.org
Precedence: list
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-Id: <201502021805.00487.vkrishn4@gmail.com>

> On Thu, 22 Jan 2015 09:49:36 -0800
> 
> Thomas Zelch <thomaszelch@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@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---