Why radeontool?
Doug Wyatt
dwyatt at sunflower.com
Tue Oct 2 01:06:10 UTC 2007
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.
More information about the fedora-list
mailing list