Why radeontool?

[Doug Wyatt]

Michael Schwendt wrote:
> *This message was transferred with a trial version of CommuniGate(r) Pro*
> On 29/09/2007, Doug Wyatt <dwyatt at sunflower.com> wrote:
>>  >Doug Wyatt <dwyatt at sunflower.com> 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 at math.uh.edu> 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.