This is an attempt to document the steps required to convert a sidux installation to testing for those installations where a more stable environment is desired. Includes my interpretation of comments from sidux and techpatterns.

Can be reversed by toggling:
2.c. "unstable" <-> "testing"
and
3.c. Rename: x80sidux <-> 80sidux

These steps have worked well on several installations.
Currently running on my laptop.

Please review for oversights, errors, corrections, suggestions, etc.

Thanks,
Richard.
=================================

1. Prepare for installation:
a) Get the sidux-kde-full DVD iso, sidux.com/Article303.html
b) Verify md5sum of ISO
c) Burn DAO/SAO at slowest speed possible.
d) Backup YOUR data
e) Select your lang and keyb (with kde-full)
f) Add needed cheatcodes. manual.sidux.com/
g) Partition with GPartEd from the liveCD installer,
suggest:

2. After install, boot the new hd installation,
as root, do the following:
a) add the testing and testing/updates sources into
/etc/apt/sources.list.d/debian.list:

b) modify /etc/apt/sources.list.d/sidux.list to contain:

c) create /etc/apt/apt.conf with distro: "unstable"<->"testing"

. . . . . and /etc/apt/apt.conf.d/80sidux has these for apt-get.

d) execute the following:


3. Get smxi: (great for after-installation configuration and regular maintenance of Debian compatible distros):
a)
b) Exit smxi at the first exit opportunity, add the line: into /etc/smxi.conf
c) Rename /etc/apt/apt.conf.d/80sidux <-> x80sidux
d) Re-start smxi: # ./usr/local/bin/smxi continue with full-upgrade (new name for d-u)
e) Install Debian apt-kernel and video driver, etc., if desired to adhere to Debian or use the sidux kernels which are very up-to-date and actualized for hardware.
f) Reboot!
g) Edit /boot/grub/menu.lst > for default boot kernel
h) Add multimedia support (look for extras script, or use debian multimedia: edit, no links to this stuff please)

4. More after install config details:
a) Install essential apps, my examples:
...and whatever else for the way you work.
b) Configure krusader, desktop, panel, background, add /data partition to fstab, etcetera.
c) Move your email store to /opt for safe-keeping. Or point your email client to it if already moved.
d) Use /opt as the shared partition with VirtualBox.
e) Leave /home in /; create a separate /data storage.
f) Use external device(s) for backup.

5. My Choices:
a) Install apps with aptitude in interactive or command line mode. CL mode sometimes seems safer or more explicit.
b) full-upgrade with aptitude or smxi on Friday afternoon;
c) After a large full-upgrade, reboot
d) re-run # aptitude update && aptitude full-upgrade
e) In case of problems, run # aptitude -f install
f) Do kernel install with smxi
g) Read all on-screen messages very carefully.

< Edited by Richard :: Oct 9, 08, 3:16 >
Back to top

ad 5g)

There should not be questionable removes at dist-upgrades using testing as base distribution. There are no dependency issues in Debian testing.

On the other hand: Debian testing is maintained by the release crew, and packages might be totally removed from testing over night and not maintained at all (they are just in Sid then). A way to track that is this site: bts.turmzimmer.net/

And one should also track Sid if packages have showstopper bugs. They might be in testing for ages when Sid already has fixed packages which cannot move into testing (maybe because of the armel architecture). You can check that here: bjorn.haxx.se/debian/

Also: when using sidux kernels (which are imho by far the best desktop kernels around - the stock Debian kernels are optimized for servers), you should not block Sid when opting for testing as main repository. The kernel headers are built against gcc in Sid and you need that gcc version for compiling modules.

hubi
Back to top

wow, excellent how to and information in this thread, thanks.
Back to top

To add that from my experience of antiX already set to Testing and using the smxi script, it is best to use the sidux kernels not from the sidux repo, but those sidux kernels from the wget provided by h2.

Otherwise, as hubi points out, the sid repos need to be enabled.
Back to top

Thanks Hubi and anti.

I made some changes, but need some info:

Where are the sidux kernels provided by h2? the wget line?

The sid and sidux repos are still active in the *.list
only the preference changes. But I didn't realize that about the kernel headers. I will add a recommendation to keep the sidux kernel instead of changing to "testing" unless one really wants to use the real "testing" kernel.


[Edit: addition]
I now have sid, testing and sidux active in my ourea2aptitude xfce sources.list. While installing kde w/aptitude I was surprised to see that about 15% of kde is coming from unstable. Guess this is an effect of the freeze for lenny?

@antix
Forgot about that :}}.
Had just set it to the sidux apt kernel and never looked at it again. Going to go pick out one of the later ones and leave it for awhile.

Wish I knew which is considered the more stable, but I guess it depends on hardware, etc.

< Edited by Richard :: Oct 9, 08, 8:42 >
Back to top

You can find 'old' sidux kernels in:
advanced-kernel-options
Select from list of archived kernels
Back to top

Just out of interest to see what would happen I installed the latest sidux in a VM, set sources to lenny and modified /etc/apt/preferences with:


I first renamed /etc/sidux-version, /etc/default/distro and removed kernel metas. The resulting large downgrade and lenny kernel install (using smxi) appeared to be successful. Very likely I missed a few important points but I did this before Richard's post.
Back to top

dzz,

that's quite a radical method. If someone wants Debian testing with sidux kernels and apps, I would suggest to install Debian testing (as h2 suggests as network installation) and then add the sidux repos and allow Sid in the sources list for dependencies from sidux. Then the pinning might be e.g. testing 990, unstable 500. But always be aware: sidux packages always might pull some packages from Sid (esp. the kernel headers).

If one chooses the fun of downgrading (it's really a good game in boring winter nights, and even better when it is your main box with no other OS installed, and to have the absolute thrill: don't backup anything!), if one chooses it: purge xorg and openoffice before downgrading (you do it out of X anyway), they can be wild beasts fighting downgrading. Also be patient: you might have to run "apt-get -f install" a hundred times and to do some --force-overwriting.

I did such fun stuff some time ago, and my pride is Sid > Sarge > Sid. Hmmm ... I was really bored that day ;)

hubi
Back to top