~alpine/devel

3 3

[alpine-devel] apk package rollback feature?

Thomas Zelch
Details
Message ID
<CABKXMoYgQtML+BV4EaYZqonvyyDdLWPaBfpQU_a5DLTERA0+Pw@mail.gmail.com>
Sender timestamp
1421948976
DKIM signature
missing
Download raw message
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
Orion
Details
Message ID
<20150122142439.483ee958@twinpeaks.my.domain>
In-Reply-To
<CABKXMoYgQtML+BV4EaYZqonvyyDdLWPaBfpQU_a5DLTERA0+Pw@mail.gmail.com> (view parent)
Sender timestamp
1421965479
DKIM signature
missing
Download raw message
On Thu, 22 Jan 2015 09:49:36 -0800
Thomas Zelch <thomaszelch@gmail.com> wrote:

> I searched the wiki and help output of apk, but couldn't find a way to
> downgrade the package comfortably.
> ...
> Is there a more comfortable way implemented?

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:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Natanael Copa
Details
Message ID
<20150129120227.2d69bb49@ncopa-desktop.alpinelinux.org>
In-Reply-To
<CABKXMoYgQtML+BV4EaYZqonvyyDdLWPaBfpQU_a5DLTERA0+Pw@mail.gmail.com> (view parent)
Sender timestamp
1422529347
DKIM signature
missing
Download raw message
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.

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.

> 
> Regards,
> Thomas



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
V.Krishn
Details
Message ID
<201502021805.00487.vkrishn4@gmail.com>
In-Reply-To
<20150129120227.2d69bb49@ncopa-desktop.alpinelinux.org> (view parent)
Sender timestamp
1422880500
DKIM signature
missing
Download raw message
> 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
---