Open MPI logo

Hardware Locality Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Hardware Locality Development mailing list

Subject: Re: [hwloc-devel] lstopo-nox strikes back
From: Guy Streeter (streeter_at_[hidden])
Date: 2012-04-25 12:39:10

On 04/25/2012 04:38 AM, Brice Goglin wrote:
> Hello,
> We recently got some complains from redhat/centos users that wanted to install
> hwloc on their cluster but couldn't because it brought so many X libraries
> that they don't care about.
> Debian solves this by having two hwloc packages: the main hwloc one, and
> hwloc-nox where cairo is disabled. You just install one of them, packages are
> marked as conflicting with each others.
> I asked Jirka, our fellow RPM hwloc packager. He feels that RPM distros don't
> work that way. They usually have a core 'foo' package without X, and something
> such as 'foo-gui' with the X-enabled binary. So you'd have lstopo and
> lstopo-gui installed at the same time.
> I don't have any preference but RPM is much more widely used than deb in HPC,
> so we must consider the issue, either in hwloc or in RPM packaging. And we
> need a solution that is consistent across distros (we don't want users to get
> lost because Debian/Ubuntu lstopo is graphical while RPM lstopo is not and
> lstopo-gui is).
> It's not hard to build two lstopo binaries in the same hwloc (quick patch
> attached). But we'd need to decide their names (lstopo/lstopo-nox,
> lstopo/lstopo-nogui, lstopo-gui/lstopo), and find a good way to make the
> existing packages deal with them.
> How do people feel about this? Is it ok to choose between hwloc and hwloc-nox
> packages on Debian/Ubuntu? Does somebody want to *always* have a lstopo-nox
> installed? Should the default lstopo be graphical/cario or not?
> Brice

Fedora generally prefers separate packages with separate commands, like
system-config-network-tui and system-config-network.

Red Hat addressed the problem in the "tuna" package for the realtime product
by simply removing the graphical package dependencies and making tuna run in
commandline mode if the attempt to start graphical mode fails. The downside to
that approach is that you have to figure out for yourself what dependencies to
install if you want the graphical output. It happens, though, that they are
standard packages that are installed for most any system with a desktop