codu Hackiki filesystem:bin/Not quite debtakeover

1#!/usr/bin/env .wiki

2Here I will record my experiments in doing something similar to [[debtakeover|http://hadrons.org/~guillem/debian/debtakeover/]]. Debtakeover hasn't been maintained in quite a while, so I'm wondering if I can do something very simple to get nearly-equivalent functionality. Basically my thinking is I can create an alternate root with just glibc, busybox and debootstrap, then debootstrap over / (which shouldn't fail because I'll be using altroot binaries). Then a simple script should be able to search files and install the Debian versions of packages.

4Most importantly, this makes //no// assumptions about the host distribution, and as a result isn't trying particularly hard to preserve //anything// from the host. It makes a slight attempt to preserve configuration files, but not much. As a result, it should continue to work indefinitely and on future distributions, unless Debian itself makes major architectural changes.

6== altroot ==

8altroot is available at http://codu.org/altroot.tar.bz2 . It's nothing impressive though, all I did was:

9 # Install glibc to /altroot

10 # Install busybox and debootstrap to /altroot, making sure they used /altroot/lib/ld-linux.so.2 as the dynamic linker instead of /lib/ld-linux.so.2

11 # Strip everything

12 # Remove .a files, i18n stuff, includes (all optional, just to make it smaller)

13 # Adjust all the scripts (find . -type f | xargs file | grep shell) to use /altroot/bin/sh or /altroot/bin/ash

14 # Adjust sbin/debootstrap to point at /altroot/share/debootstrap instead of /usr/share/debootstrap

16You should probably make your own, at least for the learning experience.

18== debianize ==

20debianize is a very simple script which generates an sqlite3 database of every package available in debian (/tmp/debian_pkgs), then figures out the mapping of installed files to those packages, and installs the debian versions over the native versions. It's provided in altroot.

22== How to do it ==

24# Make sure your current distribution is generally functioning.

25# Extract altroot.tar.bz2 to /altroot

26# Source /altroot/path ({{. /altroot/path}}), then run /altroot/bin/ash and make sure things seem to generally work.

27# {{debootstrap lenny /debian}} (of course, use any suite and target path you'd like, other than /)

28# Get rid of conflicting /etc files ({{cd /debian/etc; rm -f fstab mtab passwd shadow network/interfaces modules; cd}})

29# Copy everything from /debian into /, making sure you're still using altroot's cp. If something goes wrong, you're OK so long as you're set up to use altroot. ({{cp -af /debian/* /}})

30# Remove the now-unnecessary /debian directory ({{rm -rf /debian}})

31# Get out of altroot and into the native debian environment by running {{/bin/su -}}. If anything goes wrong, you can just {{exit}} to get back to altroot.

32# Run {{/altroot/bin/debianize}} and wait a very long time for your packages to become debianized. This is an interactive process, so don't just go away. First it has to figure out what packages to install and download them, then it installs them with a normal degree of interactivity (configuration stuff). If something goes wrong, it will drop you to a shell, and you should

33## Run {{apt-get -f install}} to get more useful error messages,

34## Delete any .deb files that //shouldn't// be installed, and

35## Fix any problems that the installation ran into. Often these problems are users already existing that it expected not to exist, so delete them (e.g. {{deluser messagebus}}). Another common one is that init.d scripts are considered configuration scripts, so it will prefer the old init.d scripts even if they don't work in Debian. So, if it's failing to start something properly, maybe you need to move an init.d script.

37(More to be written, I haven't finished testing yet)

39== Results ==

41This is currently being tested on OpenSUSE. Results to be posted. One thing I've noticed already is that Java is likely to be a problem. Debian prefers gcj (and for good reason, although now I think it should prefer OpenJDK), so you're likely to come out with a java you didn't actually want.

changeset 754:	d39e613e8266
author:	Gregor (codu.org)
date:	Mon Jan 03 22:11:26 2011 +0000 (16 months ago)
permissions:	-rwxr-xr-x
description:	medit/bin/N-in-a-row game chebang=#!/usr/bin/env .wiki cont=This is an idea for a game which: * Is entirely non-random * Has no hidden information * Involves strategy * Is playable by normal humans * Has an infinite state-space * Is hopefully fun * Is generally unsolvable ** Although it may be solvable when restricted to "reasonable" board sizes The basic idea is: * The gameboard is an infinite grid * One player starts by placing a single X anywhere * The second player must get two Os in a row within f(1) turns (f to be defined) * Generally, if you get N in a row, then the opponent has f(N) turns to get N+1 in a row or you win. Then it repeats when they have N+1 * You can also get N+1 in a row yourself, in which case the counter resets with you still in the winning position. Open questions: * What is f? * Can you place your symbol anywhere, or only next to the existing game? Of course, the most vital part is the definition of f, and we're not yet sure what to do with that.