On Tue, May 29, 2012 at 12:02:14AM +0200, Cyril Brulebois wrote:
> The dependency in squeeze (and in other suites) is:
> ati→{mach64,r128,radeon}
>
> there's no:
> radeon→ati
OK, my bad - surely some confusion on my side.
> > But the result is, GLX is entirely disabled, and we can see a "fail to
> > loat ati" messge in the log. Reinstalling them (Xorg.1.log.old
> > attached) suppresses the message, and shows much better init of
> > DRI/GLX stuff. Removing again just the -ati package, and those stop
> > to work again (Xorg.1.log attached).
>
> ati is a wrapper which does the right thing, don't remove it. Or set
> radeon as driver in xorg.conf if you insist on doing so (man radeon).
OK I understand that there is no absolute requirement for -ati, and
thus a Depends is probably not a good idea for some users. But for
the vast majority, who will want to use it, what about adding a note
in package descriptions of {mach64,r128,radeon} that the -ati package
is required to avoid manual Xorg configuration ? Adding somewhere the
suggestion to set the driver in xorg.conf (package desc or manpage),
to avoid depending on -ati, would also be a good idea.
Even then, why this Depends of ati on all 3 drivers ? I can "dpkg -r
--force-depends" both mach64 and r128, and ati+radeon does startup
without complaining at all. Shouldn't this be downgraded to a
Recommends as well ?
The current situation just makes some people (eg. me ;) break the
dependency link that's the weakest to get rid of useless drivers, with
the results described in my original report.
If I check the Policy about Depends, "This declares an absolute
dependency", which is clearly not the case here. Even the official
definition of Recommends makes me wonder if it would not be too
strong. After all, someone with a radeon is likely to select the
readon driver, then the ati wrapper will be selected as Recommended,
but the latter should IMHO have no reason to pull mach64 and r128,
that would not fit the "packages that would be found together with
this one in all but unusual installations" criteria.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
