Void Rollback Machine?



I’m a longtime archlinux user making the transition to void. (sound familiar? 8-))

One feature of the arch infrastructure that I’ve come to use routinely, is the A.R.M. (arch rollback machine), now known as archive.archlinux.org, as described here (see the history section):


With the rolling release it is difficult to “lock down” an installation to a specific set of dependencies/versions. As a software developer, I don’t want to change versions of Qt or GCC in the middle of a project. However I’ll sometimes want to install a new package (without updating the whole system).

The archive is an incredible tool for this. I simply replace the Server line in the pacman mirrorlist with a link to a specific day in the archive repos, and after that all updates come from that point in time (when hopefully, all packages are mutually compatible).

The archlinux archive is updated with the state of the package repos everyday. For my purposes (and perhaps many others) it wouldn’t be necessary to include a snapshot everyday. Even once a week or so would be sufficient.

Is there some possibility that an archive/rollback machine feature could be implemented for Void Linux?

Thank You!



Void used to have an archive exactly like arch’s.
One day it was gone, never to be seen again without any public announcement.


Hmm, that’s unfortunate.

Hopefully this feature finds its way back.

As a work around, one can snarf the entire binary repo on the day of performing an update. Then use it locally to add additional packages as needed.

Personally, i only do a complete system update once a year or so, unless there’s a specific new feature or bug fix that i need.

Thank you for the info cardinal!


Well if its connected to the internet, that’s not really a good idea.
Even if you would use a distribution like debian which would better match your update policy its advised to update packages for security patch issues.

The old archive took to much space, void does not have the storage capacity to store daily snapshots of the repo over a longer period of time.


Duncaen is right, and I may add, you will always need bug fixes, and will never know them all well enough to do as you propose. It’s just code today. It’s why rolling releases rule. If you want bitrot, use Debian or FreeBSD.

Explore virtual machines which are easy to snapshot and archive. You could run Debian Bitrot Edition in a VM on Void.

If you just need certain packages held back, read the --mode options for xbps-pkgdb command.

Anyone can keep /var/cache/xbps on a gigantic disk to archive old packages until kingdom come or the disk chokes, whichever comes first.


As a software developer, you should be developing for the platform of your users. Use that.

^ That’s really wrong. Unless 100% un-networked and locked down in a safe room.


Thanks so much for the thoughtful concern.

After using a linux workstation as my daily desktop and development machine for a few years. I settled on the arch distribution at release 0.4 dragon, in 2002.

So far, in my experience, once I get an installation where everything, as I use it, is working for me, the most likely thing to break it is the next update.

I’ve had many many more experiences of updates breaking some aspect of the system, than having some problem due to running the 6 month old version of an application instead of the very latest one.

In spite of this, I still think rolling release is superior.

With rolling release I can choose up to the very latest version of anything. When I want a new feature (e.g. qt5 w/ qml (although not so new anymore, this is just an example)) I update, test and repeat until all of my specific inter-functionality requirements are met. Then I lock onto that day’s rolling release snapshot, and use it until I need to update again for some specific reason.

In this way I create my own “release” with the combination of libraries, frameworks and applications that are serving my needs, instead of having redhat or canonical choose the release configuration for me.

I can’t think of one instance where after getting things running, some later discovered security vulnerability or bug, broke the install. In practice the thing that breaks the system has been updating. I avoid it like the plague :sunglasses:

It reminds me of the old K&R joke about the flexibility of unix: It gives you all the rope you need to hang yourself, and then 10ft more :sunglasses:

That’s why we like the configurability of toolkit type distros like void and arch, because they let us do things exactly the way we want to do them.


@Duncaen, Thank You for the insight into the historical issues of trying to maintain daily snapshots. I have to believe it starts to pile up into truly massive storage requirements. I hope the resources available to the void infrastructure increase to the point where such a feature becomes practical again.

Very Sincere Thank You for the replies!


You’re creating a snapshot release distro out of a rolling distro. Just use a snapshot distro and save the work. There is no reason for you to think rolling release is superior, using it the way you do, and in fact you are cheating yourself out of the work done by snapshot distro teams, to do it all yourself. I think you should join a snapshot distro and help it out.


Sorry you feel so strongly about it.

I’ve been using this methodology for about 15 years and it’s working really well for me.

I hope you’ll use the distro of your choice in the way that you find works best for you.


Feelings are not involved. I also use snapshot distros. Snapshot teams devote a lot of effort to releases.

(Mike Scott) #12


I am a newcomer to Void; have used Arch; I am going to stick my neck out and throw out the idea that came to me and if it is foolish, someone will say so and I will not be offended.

The comments seem to indicate that the problem is the volume of storage that would be required to keep each and every binary package that had been built and included into the Void repos; that there is only enough storage to keep the current versions.

I went to the the page for the “continuous build system” and it seems to be an open source project that one could download and use yourself; I am not sure how much, if any, that the creators of Void have customized this buildbot. I suppose that even if they did not have to modify the source code a lot, there would still be a lot of setup of parameters, regarding how to obtain the upstream source which is to be built, etc., etc.

  1. someone could tell, how hard would it be for a user of Void to have the “buildbot” set up and configured on their own PC, just as it is done at the main Void project itself, except that the user could specify what version of the code was desired to build for each package which was to be built.

  2. it would seem likely to this newbie, that this type of specialized building, would probably only be needed by a very small percentage of the users of Void, but those that need it, really need it. What if, a second instance of the Buildbot, could be operating, and when any user needs a non-current package, they log in and request it to be built by that buildbot, then when it is done they can download it, and it would be kept in a “cache” for some short time, like, i.e. 7 days (or 3 days, or whatever) and if someone else requests the same thing in that time, they receive it immediately and the timer is reset, such that only the older packages that are actually in demand are there and taking up storage, and the rest are discarded when they time out.

What would it cost to set up such a thing? How many of us would contribute toward getting it done?



Keeping pretty much updated is sensible. I can see why you might leave it for a bit if you were busy and were needing your OS constantly, and couldn’t afford the risk of some downtime to resolve an update issue when everything is running well, also if you had a download limit, updating every 5 minutes and going through every possible minor version gets a bit much. Once a year is probably rather extreme though. Some people don’t interact with anything ‘secure’ online, on particular machines at least. Potentially this could still create vulnerabilities to others on the same network connection though. Void (almost) never breaks on updates, it is all super well tested. If there are any small bugs they are mentioned on the forum or github and quickly fixed, you can check before updating if anything is relevant to your install. I have heard of the Arch ‘don’t update’ strategy elsewhere too, but it’s not needed with Void as there are so many less issues.

(aleksey) #14

Umm, I’m not sure if I’m getting this right, but void packages are on the GitHub, right? And git is a version control system, right? Has anyone tried to clone void packages, roll back to revision with a specific version of a package and build it?

I think one could also Branch out of master and keep his own local repo with stable version of packages, no? Then do something like cherry picking updates from master?

Am I saying something stupid?

Or maybe I wasn’t clear enough. Have anyone tried to use xbps-src in combination with git to archieve effect of way back machine?

(maxice8 alter) #15

No, just massive amount of work.

(aleksey) #16

Huh? I just tried here with a series of git checkout <revision> followed by ./xbps-src pkg -f ccache:

[alex@localhost void-packages]$ ls hostdir/binpkgs/
ccache-3.4.1_1.x86_64.xbps  ccache-3.4_1.x86_64.xbps
ccache-3.4.2_1.x86_64.xbps  x86_64-repodata
[alex@localhost void-packages]$ xi -f ccache-3.4_1
[*] Updating `https://repo.voidlinux.eu/current/x86_64-repodata' ...
[*] Updating `https://repo.voidlinux.eu/current/nonfree/x86_64-repodata' ...

Name   Action    Version           New version            Download size
ccache downgrade 3.4.2_1           3.4_1                  - 

Size required on disk:         190KB
Free space on disk:             16GB

Do you want to continue? [Y/n]

Revisions i’ve found in git log by searching for “ccache”, pkg -f to overwrite repodata, now i can downgrade ccache, no? Isn’t that what was wanted originally?

(maxice8 alter) #17

you did for 1 package, do it for lots of packages over a long time.

I also did it for Freetype-2.8.2 when wine was broken and it quickly became a pain since 2 other packages also needed to be downgraded.


For the case of upgrading now and again then XBPS can handle that and still let you install new packages without updating every time first:
If you installed your archive system and an xbps-src install at the same time, and updated neither, I think you might be able to continue to use xbps-src. What happens is when it cannot find the correct binary make deps it starts building the versions required from source as well, then caches them for future use. So probably that set up would work indefinitely, if the upstream sources are still available.
If you could reset the entire xbps-src tree to an earlier state with git, that might work too. BUT - git in xbps-src has a lot of stuff in git-ignore. For that reason I have found it is better to keep the original xbps-src unused then cp -a the whole thing and use (or accidentally ruin) a copy because even git revert might not save you when using the original, then you need to start afresh with a new git pull. So I don’t know how reverting to an earlier timeframe with a tree that hasn’t been destroyed by some faulty attempt to create a new package would work out.