Part 1 - apt.conf
Of interest to some might be this configuration:



I'm thinking of exploring straight sid, but in many ways, this would be far more attractive, since if it works, it will in theory provide sid packages not available in Testing, while retaining the stability of testing.

This to me sounds like the best of both worlds, but as with all such considerations, speculation is worthless, real world experience is the only true determinant factor in this.

Especially with aptitude, which I find problematic on its edges, especially with Sid.

Make sure to read up on apt.conf syntax before you dive too deeply into this area.

Part 2 - apt preferences
More information on apt preferences



Always details...

In theory, the above configuration, if adjusted for testing/sid priority, no stable, would result in apt installing all packages available in testing and sid from testing, and installing only packages available only in sid, not testing, from sid.



That's the theory, let's see how reality works out.
Back to top

@h2,

I am doing this since 21-sep-2008 with no problems. I originally converted my everyday, up-to-date Core2duo sidux box, but since have installed on a Lenovo 3000 C200 and an Acer Aspire One ZG5 using sidux for the install then immediately add testing sources and create apt.conf and set: APT::Default-Release "testing";

I do not use a preferences file. Preferring to let the sidux packages come in as required. I'm still a sort of d-u junkie but so far without problems.

I use aptitude only, cli and interactive, and use smxi for the first dist-upgrade and config. Since I changed to tracking testing I have not had occasion to try to "hold" any packages; therefore, the "aptitude hold problem" is not an issue for me. The only holds applied were via smxi but none lately.

NOTE: Currently have all sid/sidux sources commented due to the influx of Kde4.2. I will reactivate sid/sidux on the AA1 when the churning slows down. That is the only time I have deactivated sid sources [since a short period when first begun].
Here is my current procedure, recently applied on the AA1 with Ouranos using the latest slh kernel, without my partition layouts. [Updated the AA1 to Kde4.2.2 tonight, AOK. Just takes some getting used to. Still waiting for the desktop.]

<begin sidux2t notes>
sidux2t: sidux2testing: a rolling distribution tracking Debian testing with regular full(dist)-upgrade using aptitude, interactive and command line. Installed-2008-09-21

IMO, the best of both worlds: the great selection of apps in sidux with full, quarterly up-to-date releases; while less chance of breakage by tracking testing. sidux developers do not condone, recommend nor support the use of aptitude (nor testing).
# apt-show-versions | grep sid > installed-080921-sid.lst

1. Prepare for install: (Select lang and keyb: lang=es-ES)
a)Get sidux-kde-full DVD iso, about 2 GB, sidux.com/Article303.html
b)Verify md5sum & burn DAO/SAO at slowest speed possible for the media used.
c)Backup these: /data, /var/cache/apt/archives, /home/<user>, /boot & /etc; Firefox bookmarks
d)Read the manual, manual.sidux.com/. (for fromiso, installation, etc.)
e)Partition with GPartEd from the liveCD. Partition suggestions: (see ##7, 9, 10, 11)
/ [10-15%], swap [1-3%], /opt [10-15%] & /data [79-67%]
2.After installing from DVD, CD or ISO, re-boot; then as root, do the following:
a)Add testing, testing/updates & other sid sources to /etc/apt/sources.list.d/debian.list:
deb ftp.us.debian.org/debian/ testing main contrib non-free
# deb security.debian.org/ testing/updates main contrib non-free
deb security.debian.org/ lenny/updates main contrib non-free
deb ftp.us.debian.org/debian/ sid main contrib non-free
b)Add these changes to /etc/apt/sources.list.d/sidux.list:
deb sidux.net/debian/ sid main contrib non-free fix.main fix.contrib fix.non-free
c)To track testing, create /etc/apt/apt.conf and add these lines:
APT::Default-Release "testing";
Aptitude::Recommends-Important "false";
Aptitude::Suggests-Important "false";
APT:Cache-Limit 26000000;
d)then execute: # apt-get update && apt-get install aptitude && aptitude update
3. Execute these lines to set smxi to use aptitude; then download smxi and inxi :
# echo 'apt-type=aptitude' > /etc/smxi.conf ;; and then
# cd /usr/local/bin && wget smxi.org/inxi && chmod +x inxi
# cd /usr/local/bin && wget smxi.org/smxi.zip && unzip smxi.zip && smxi
a)Suggest option 3 to install the latest sidux kernel and to turn off automatic kernel updates.
(or pick a late model sidux kernel), re-install video driver for Nvidia, if used.
c)Edit /boot/grub/menu.lst to select the default boot kernel, if necessary.
d)Go to: debian-multimedia.org/ to add multimedia support.
4.Install my essential apps, for example:
# aptitude install aspell aspell-en aspell-es conky gdb gstreamer* gxine i2e icedove iamerican ispanish ispell kdiff3 krename krusader libdvdcss2 liveusb-creator moc myplayer myspell-en myspell-es omegat pidgin rapidsvn rdiff‑backup sun-java6 w32codecs wordtrans-dict ...etcetera.
a)More non-free apps available via smxi.
b)Configure krusader, desktop, panel, background, add /data partition to /etc/fstab
5.Choices:
a)Use only aptitude for package management in interactive or command line mode, full-upgrade on Friday afternoons. [Do not mix aptitude with apt-get or synaptic. Use one or the other.]
b)Run # aptitude -f install in case of partially installed app or interruption.
c)Kernel install/removal with smxi. H2's inxi is a new tool to show hardware info.
d)If in doubt, don't do it. Wait and see. Read all on-screen messages very carefully.
6.Partition suggestions:
a)Create /opt partition for apps, info & VirtualBox. Create /opt/share for win stuff.
b)One-time: move contents of ~/.thunderbird/*default to /opt/tbird.default
On each new install, edit ~/profile.ini: IsRelative=0 & Path=/opt/tbird.default
c)Use /home in /, create a separate /data partition, and auto in /home/<x>/data
d)Use external device(s) for backup.
7.Useful tips:
a) a)RSEISUB: Raising Skinny Elephants Is So Utterly Boring. Alt-SysReq-RSEISUB and RSEISUO
*My partition choices omitted.
</end sidux2t notes>

This has been working well for me. Looking forward to seeing stable Kde4.2? Will probably keep my desktop running Kde3.5.10 until KDE 4.x is really stable and complete.

regards,
Richard.

< Edited by Richard :: Apr 8, 09, 19:46 >
Back to top

Hmmm....That setup sounds a lot like a certain Linux+ article I had the pleasure of reading. :-)
Back to top

Thanks for that feedback Richard, here's a few things to make it easier:


Make that step easier by simply doing this before you start smxi the first time, as root:



If you've never run smxi on the system, the touch /etc/smxi.conf isn't necessary, and you can just do:


then start smxi after you've installed aptitude.

You can also start and run scripts from the internet with the -X option. so: smxi -X myscript#domain.com/script
would create that script as a post du fix item with the name: run-myscript. The download url is the part after the #. This is useful for an initial setup to get all the stuff running the way you want. You can make the url short using dyndns or something, and just load a script that does all the stuff you want, or get some from online.

I have to strongly disagree with your rseiub, I much prefer:


thanks for the good feedback, I think this direction is really the way of the future in some shape or other, but we'll see how things evolve.
Back to top

Thanks for the tip to echo the smxi.conf. Knew there was a way to do it but this started out as notes to myself. It is just the way I use sidux which is a First Class distro. I just enjoy not breaking things as much as I used to. I keep trying others: Mepis and Dreamlinux most recently. They are good for their purpose but I keep coming back to sidux2t.

As for, RSEIUB and RSEIUO or REISUB and REISUO?

I used the former pair for quite a few years; found it in a Mandrake forum about . Worked fine for me. Then I read some good arguments about the variation, and changed. It still works for me. Either way seems to work for me.

But in this I'm just a copy-cat. Here is one of the arguments that led me to try the new version. renesto.blogspot.com/2007/10/raising-elephants-is-so-utterly-boring.html

This is another of those accepted tech tips that needs investigation and proving.

PS: Thanks for smxi and congratulations. rh.
Back to top

Thanks. I feel it is a bit more defined than the article.
They have a long lead time with not much time for editing.
Still using GoinEasy9-dark-ourea.png. It just feels right,
no matter the version and hasn't gotten old.
Back to top

Just thought I'd add, because I need a machine to remain working, I decided to test an old sidux chaos install, last dist-upgraded 3 weeks or so ago, so I pinned it to testing using the /etc/apt/apt.conf method, then with some nervousness tried a sample full-upgrade with aptitude, and it was perfect.

Then I tried smxi, again nervously, to see if it would try to convert to kde 4, and no, it doesn't.

That's because this pinning method is smart, apt simply offers as a candidate anything that is in testing and sid the testing version, so it was totally smooth.

Very nice.

Also, I downgraded to uswsusp to fix a lingering suspend issue in the sid package, and that fixed it, and, happily, in the full-upgrade, the package did not upgrade, since testing version was what was installed.

All in all a very pleasant experience so far.
Back to top

Happy to hear that it is working well for you.

Just an unrelated thought, I think sidux2testing is the only possible route for a remaster of sidux. Just don't have the time to learn all the ins and outs. But actually, for that there is Dreamlinux which makes it easy to build a CD for pre-school that I can install on unconnected boxes. Sure saves lottttttss of configuring.

I uncommented the sid and sidux sources after kde4.2 seemed to be updated if not complete. Actually only had them off for a few days.
Back to top

Interesting. I like to follow sid but don't want kde4.2 and am looking into methods of keeping it out while running as much sid (or testing) as possible. When kde4 hits testing with the configuration posted here might get left with security issues and bugs which won't be fixed else enforced kde4

Possibly a variation of apt.conf with stable as default and apt-preferences as suggested here?

I made a post techpatterns.com/forums/post-4130.html#4130 before I read this with a possible solution to keep out kde4 but am still undecided what to do.
Back to top

The danger of starting with sid and pinning to stable is that not all packages in sid are in testing or stable.

So over time, and I already see this in my sid started, but pinned to stable, system, you'll get packages failing that were in sid.

You need to remove sidux and sid sources, and testing, then do a full dist-upgrade, but it's risky, and it gets riskier the further from sid you get.

It should work, but you need to be aware, as I have already found, that the ideal way to pin is to start with the system you want to actually run, and then pin to that, and use sources from say sid or testing, but the older stable gets, the less chance of that working.

Stable really should just be stable, it doesn't mix well because it doesn't track testing or sid.

But we learn by experimenting.
Back to top