Re: Why radeontool?

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

 





Michael Schwendt wrote:
*This message was transferred with a trial version of CommuniGate(r) Pro*
On 29/09/2007, Doug Wyatt <dwyatt@xxxxxxxxxxxxx> wrote:
 >Doug Wyatt <dwyatt@xxxxxxxxxxxxx> writes:
 >> Yesterday, when I ran 'yum update' on F7 I got two packages
 >> installed for which I can't find a reason (see yum log
 >> excerpt below).
 >>
 >> The two new packages are vbetool and radeontool.  From
 >> what I can find, both used to be part of pm-utils.
 >>
 >> I really don't know about vbetool, maybe it's needed, but
 >> radeontool is described as:
 >>    "radeontool is a hack to save some battery on an
 >>     ATI Radeon Mobility graphics chip. Radeontool can
 >>     turn off and on the backlight and external video
 >>     output."
 >>
 >> But, my platform is a desktop, not a laptop, with a GeForce
 >> 6800 GT video card.
 >>
 >> Using yumex, I tried uninstalling radeontool to see what
 >> depended on it; there were nearly 200 of them and pretty
 >> much none of those were optional. They included most of
 >> the OpenOffice pkgs, Control-Center and system-config-*,
 >> for example.
 >>
 >> Can anyone explain, or even speculate, why radeontool?
 >>
 >
Jason L Tibbitts III <tibbs@xxxxxxxxxxx> wrote:
 > It (and vbetool) were split out of pm-utils.
 >

If I assume that you saw that I noted this, myself, then
may I assume that you imply that radeontool became a
dependency simply because its parent package was one, and
not because it's actually needed?

It seems so. To put it bluntly, the packaging causes "dependency
bloat" and is poor since it requires radeontool even where no Radeon
cards are used. Else it's like before. It's just more obvious that
something unneeded is installed. The only advantage the introduction
of the two new packages gives is that they can be updated separately
without having to update pm-utils.

$ rpm -qR pm-utils|grep tool
radeontool
vbetool

However, since pm-utils requires them and pm-utils is difficult to get
rid off, the two extra packages cannot be removed either.

$ rpm -q --whatrequires pm-utils
apmd-3.2.2-5
hal-0.5.10-0.git20070925.fc8

If you examine the files in the pm-utils package, both tools are optional:

  /usr/lib/pm-utils/sleep.d/20video
  /usr/lib/pm-utils/sleep.d/99video

        if [ -z "$radeontool" ]; then
               echo "radeontool not found" 1>&2

        if [ -z "$vbetool" ]; then
               echo "vbetool not found" 1>&2

Is this also because RPM is blind to hardware, beyond CPU
architecture?

With radeontool and vbetool, both packages were made a strict
requirement at the package-level. Together with pm-utils you always
get the other two.

It would be rather limiting if RPM stopped you from installing
packages which contain something made for hardware that is not
available, if this meant that you could not work on that software (and
e.g. debug it or develop it further). Similarly, it would be highly
questionable if RPM itself stopped you from removing packages made for
available hardware components (as in "you've got a tv card in the
computer, so you must not remove the corresponding driver pkg").
Suggestions like that belong into a higher-level installation
management tool, which would handle all _optional_ package
dependencies and tell the user whether something is mandatory or only
a soft dependency.


Thanks, that fills in a lot of gaps in my perspective.


[Index of Archives]     [Current Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux