[clue-tech] Re: Hello sidux?

[Collins Richey]

On Mon, Mar 31, 2008 at 9:07 PM, David L. Anselmi <anselmi at anselmi.us> wrote:
> Collins Richey wrote:

> The intent of sidux
> > is to provide a filter to help users avoid the occasional grief caused
> > by packages in sid that really weren't adequately tested.The principal
> > effort is in detecting and holding back (temporarily) such packages
> > until upstream has provided a fix.
>
>  I wonder what the real criteria are.  Are they trying to avoid packages
> whose dependencies aren't adequately mature so have install problems, or
> trying to avoid packages that don't work after install?
>

Yes, I've seen numerous instances of both cases. Fairly recently
versions of openoffice (separate occurrences) were released to sid
that either were incomplete (erroneous dependancies) or broken
(particularly spreadsheets). The smxi maintainer reacts rapidly to
such conditions. It doesn't take long before replacement packages
arrive, but even now the scripts are still checking for erroneous
dependancies in case anyone dived in at the wrong time with
openoffice.

>  I use sid (sort of started by accident).  I've
> yet to see a new version of software that worked less well than the previous
> one.

Obviously you missed the cutover to the more current versions of xorg
- ca. Nov.-Dec. 2007. This was badly broken and certainly never really
tested by the sid developers. I hadn't learned to read the warnings
before upgrading at that point, so I had to follow the workaround and
dip back to xorg 'testing' packages for a few days.

>
>  I have seen issues where a package can't be upgraded because its depends
> aren't satisfied in sid.  Sometimes the suggested fixes seem bizarre (but
> it's trying to fix a "shouldn't happen" situation).

The testing group at sidux and the xmxi maintainer insure that very
few users are exposed to this. They do offer up workarounds for the
unfortunate few, but mostly they just hold back the packages until
newer versions are ready.

>
>  I have also seen issues where upgrading the kernel leaves you without
> wireless because the corresponding module package isn't ready yet (and
> dependency handling doesn't catch that).

Yes, and that does happen occasionally. As soon as the situation is
known, that kernel drops our of eligibility (almost instantaneously)
for installation as a standard kernel. My experience thus far with my
laptop has been that by the time I get around to upgrades on the
weekend, someone else has reported the problem and the kernel is held
back or superseded. I did have to reboot once to the prior kernel when
a new wrinkle appeared with nVidia support. Since sidux in typical
Debian fashion never eliminates the prior kernel, that's not much of a
problem.

>
>  So really, the "unstable" part of sid has to do with whether a given set of
> packages can be upgraded easily at a particular time.

Actually no. It's not just sets of packages. Broken packages do slip
through. Most but not all of these are filtered out by the sidux
testing group. The forums are filled with trivial and not-so-trivial
examples of packages with undiscovered "opportunities" that have
slipped through. Nothing will render unstable completely stable.

> But (at least with
> aptitude) it isn't hard to notice that something odd is happening and either
> wait for more packages to upload or tweak it until it works.

IANAAE - I am not an apt expert. Since the sidux maintainers (who are)
claim that non dist-upgrade updates can produce breakage, I take them
at their word. In essence, there's probably nothing they do that you
couldn't reproduce manually with the appropriate aptitude commands,
but I like the fact that those-who-know-better-than-I have
predetermined the appropriate upgrade sequences, and thus I don't need
to make that wheel any rounder. Also the fact that a standard, orderly
set of upgrades for module-dependent stuff (nVida, ATI (crap card,
doesn't work worth a damn, but that's not a sid or sidux problem),
wireless, virtualbox, etc., etc. is handled in an equally standard
fashion. Also integrated is a standard procedure for removing older
kernels including all the related fragments - not exactly brain
surgery, but it's another part of the integrated whole that I don't
need to worry about.

They could probably get by with running upgrades under X in many
cases, but they have taken the paranoid approach to cover the edge
cases where X/kde might die or behave badly until restarted. I've even
seen a very few cases where kde does not work well after dist-upgrade
until a reboot.

>
>  Tweaking upgrades isn't a very useful pastime, but it isn't hard.

Not rocket science, but tedious.

> Usually
> packages migrate to testing quickly and I've never seen a dependency problem
> there.
>

I'm not putting down pure sid or testing; I just happen to like the
results I've seen with sidux - sid with less grief. Neither sid nor
testing is really designed for mission critical stuff. I certainly
wouldn't want to maintain a bevy of sid systems even with the extras
provided by sidux.

I became disenchanted with testing (ca. one-two years ago) when I
discovered that the standard kernel was just enough downlevel that my
sound card (nVidia MCP61 MB) wouldn't work. Since I had been using the
card for months with Ubuntu and other distros, I didn't want to wait
around or tinker with experimental kernels. testing has probably
caught up by now, but I don't really need another Debian system to
worry about, since sidux works for me.

To summarize: there's almost nothing that sidux provides that a savvy
user like yourself can't do manually with pure sid, but I'm not quite
so savvy and I like the extra degree of handholding provided by sidux.

As I've mentioned in other posts, I also appreciate the fact that the
sidux developers fully participate in discussions on the forum, and
they are responsive to requests for changes where those changes fit
the overall philosopy.  I even had one of the developers respond to me
offline about one of my questions that couldn't be discussed on the
forum - some internal changes (dirty laundry) that weren't for public
consumption.

Thanks, Dave. I'm always happy to hear well-reasoned responses that
point out the flaws in my logic. An extra pair of eyeballs never hurts
in any endeavor.

-- 
Collins Richey
 If you fill your heart with regrets of yesterday and the worries
 of tomorrow, you have no today to be thankful for.