[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

last chance to do something about discover1 etc: I give up



For years and years, X has had a unique special case: It needs to have
discover1 and some other software (currently also xresprobe[1]) installed
before it is preconfigured. If the software is not installed then X's
config script will silently not use it during hardware detection, and
will do a worse job of generating xorg.conf than it would otherwise.
Installing the software in the same apt run as X won't work, so it can't
just be a predependency.

For years and years, I've been tripping over this special case, and
executing various pratfalls. In woody, the result was that this stuff
wasn't installed in time, and things sucked. In sarge, we managed to
make it work, at the expense of a lot of wasted time in coding and
testing special cases. I think it didn't work in all cases still. In
etch the latest fun is that tasksel can hang in some cases when it's
trying to install this stuff. (See bug #386244.) I'm tired of this
special case making me look like a fool, and I'm very tired of it
wasting days of my time.

I've asked the X maintainers before, many times, if they could please
fix X so it doesn't abuse its config script to do hardware detection. If
it did it in its postinst, there would not be any problem at all. I've
been fobbed off repeatedly. This is my final plea for you to do it, and
do it *now*, not in some future planned grand rewrite.

If it doesn't happen soon, I'll have to pursue some other fix. Current ideas:

* Remove the special case from tasksel. It will make X tend to run
  without the hardware detection tools it needs, which might end up
  being an RC bug (on X).
* Bloat the base system by adding all the hardware detection tools that
  X needs to it. This works because if X's config script needs something
  from base to run, that's normal, and no longer a special case. It
  sucks because having discover1 and xresprobe in base is crazy bloat.

-- 
see shy jo

[1] And, reading the code, maybe prtconf on sparc, although that's not
    currently done. The set of programs changes occasionally.

Attachment: signature.asc
Description: Digital signature


Reply to: