| View previous topic :: View next topic |
| Author |
Message |
fpemud
Guru
Joined: 15 Feb 2012
Posts: 349
|
 Posted: Wed Apr 25, 2018 3:35 am Post subject: Will portage become "transactional"? |
 |
|
I just found out GNU Guix is a "transactional package manager".
| Quote: | Dependable. It comes with the GNU Guix package manager, which in addition to standard package management features, supports transactional upgrades and roll-backs, unprivileged package management, per-user profiles, and more.
|
I think this feature is great.
Will portage be "transactional" in future? |
|
| Back to top |
|
 |
mimosinnet
l33t
Joined: 10 Aug 2006
Posts: 713
Location: Barcelona, Spain
|
| Posted: Wed Apr 25, 2018 5:57 am Post subject: |
|
|
Which are the "transactional" features? This post, considers:
The system works fine.
User upgrades a set of packages.
The system does not work anymore.
User wants to roll back to state 1.
This other thread discusses the advantages and disadvantages of a transactional package manager. Among other issues it considers:
| Quote: | | You write down all the details of a very specific, reproducible software stack, but you do not make that software much more composable or extensible than it already was. The user can install the version combination that you packaged, but can they easily try their own? Can they easily try to build with a different compiler/compiler version/set of compiler flags/dependency version/etc.? |
From what I understand, transactional means that, after emerging a set of packages, it would be possible to uninstall these packages to a previous state by uninstalling them as a set. The guix configuration files seem to suggest you need a declaration of the packages that are installed/uninstalled.
Your post made me realise that portage can install packages on non-root locations  
Cheers!
_________________
Please add [solved] to the initial post's subject line if you feel your problem is resolved.
Take care of the community answering unanswered posts. |
|
| Back to top |
|
|
Torro
n00b
Joined: 16 Apr 2018
Posts: 18
Location: Western Europe
|
| Posted: Wed Apr 25, 2018 8:39 am Post subject: |
|
|
| wrt. rollback: you can utilize quickpkg and simply reinstall with emerge when needed. |
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Wed Apr 25, 2018 11:47 am Post subject: |
|
|
fpemud ...
there is a cost in terms of disk space if the package manager is handling such rollback (ie, with binpkg, or whatever means guix uses). I better approach would be to have the filesystem do the transaction, similar to what you find in FreeBSD/TrueOS with ZFS boot environments.
best ... khay |
|
| Back to top |
|
|
yoshi314
l33t
Joined: 30 Dec 2004
Posts: 850
Location: PL
|
| Posted: Thu Jul 12, 2018 8:56 am Post subject: |
|
|
| Torro wrote: | | wrt. rollback: you can utilize quickpkg and simply reinstall with emerge when needed. |
that's fine and all, except for situation where you want to downgrade glibc for some reason. or other core library which might have changed ABI.
_________________
~amd64
shrink your /usr/portage with squashfs+aufs |
|
| Back to top |
|
|
Maitreya
Guru
Joined: 11 Jan 2006
Posts: 441
|
| Posted: Thu Jul 12, 2018 10:28 pm Post subject: |
|
|
IMHO the filesystem snapshot is the more correct way to handle this.
Rolling back usually means undoing the steps in reversed order which also might not execute properly. And not all changes might have been recorded? |
|
| Back to top |
|
|
The Doctor
Moderator
Joined: 27 Jul 2010
Posts: 2678
|
| Posted: Thu Jul 12, 2018 11:23 pm Post subject: |
|
|
Sounds to me like a feature for people who have never had a hard drive fail. Wait, I meant people who don't do backups. I get those two confused but I guess they are basically the same group.
_________________
First things first, but not necessarily in that order.
Apologies if I take a while to respond. I'm currently working on the dematerialization circuit for my blue box. |
|
| Back to top |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21633
|
| Posted: Fri Jul 13, 2018 2:00 am Post subject: |
|
|
| In theory, rolling back to a filesystem snapshot or to a defined transaction point should be faster than restoring the affected packages from backup. Depending on backup timing and what upgrades are later rejected, it might also be possible to retain a greater number of desired changes by rolling only to a transaction point instead of rolling to the nearest backup. For example, if you maintain weekly system backups, but upgrade every 2-3 days, you might need to redo several days worth of good transactions if you were forced to revert to a nearly-week-old backup. A well-managed transaction system (or filesystem snapshot design) might let you roll back to the minute before the first unwanted upgrade, retaining all the desired upgrades of the preceding days. |
|
| Back to top |
|
|
The Doctor
Moderator
Joined: 27 Jul 2010
Posts: 2678
|
| Posted: Fri Jul 13, 2018 2:17 am Post subject: |
|
|
True, however that is a lot of overhead for a feature that you might only use a few times a year if that.
_________________
First things first, but not necessarily in that order.
Apologies if I take a while to respond. I'm currently working on the dematerialization circuit for my blue box. |
|
| Back to top |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21633
|
| Posted: Fri Jul 13, 2018 4:15 am Post subject: |
|
|
| Indeed, under current usage it's not needed often enough to be worth it. As is, using testing or masked packages carries some risk of breakage, so it should only be done on systems that can afford the downtime when something breaks. However, if rollback were trivially easy, people might be more willing to live on the edge on systems that are currently upgraded very cautiously. |
|
| Back to top |
|
|
|
Portage & Programming
