Re: [hwloc-devel] lstopo-nox strikes back

[Jeff Squyres]

On Apr 27, 2012, at 1:41 PM, Paul H. Hargrove wrote:

>> Ok let's put a X server inside hwloc then.
> 
> No, Xlstopo should be for showing me the logical->physical layout of screens 
> on a multi-headed X server, right?


Is there an iOS/android app in progress, too?

;-)

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [hwloc-devel] lstopo-nox strikes back

[Paul H. Hargrove]

On 4/27/2012 10:39 AM, Brice Goglin wrote:

Le 27/04/2012 19:22, Samuel Thibault a écrit :

Brice Goglin, le Fri 27 Apr 2012 19:09:47 +0200, a écrit :

Le 25/04/2012 15:42, Jiri Hladky a écrit :

I would vote to make lstopo ASCII only and introduce new GUI binary
"lstopo-gui" in the version 1.5

I'll commit that during the weekend unless somebody comes with a better
solution.

Of course, distros are free to add symlinks as Xlstopo then :)

Xfoo is kinda reserved for X servers, not for X applications :)


Ok let's put a X server inside hwloc then.



No, Xlstopo should be for showing me the logical->physical layout of 
screens on a multi-headed X server, right?


-Paul

--
Paul H. Hargrove  phhargr...@lbl.gov
Future Technologies Group
HPC Research Department   Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory Fax: +1-510-486-6900

Re: [hwloc-devel] lstopo-nox strikes back

[Brice Goglin]

Le 27/04/2012 19:22, Samuel Thibault a écrit :
> Brice Goglin, le Fri 27 Apr 2012 19:09:47 +0200, a écrit :
>> Le 25/04/2012 15:42, Jiri Hladky a écrit :
>>> I would vote to make lstopo ASCII only and introduce new GUI binary
>>> "lstopo-gui" in the version 1.5
>> I'll commit that during the weekend unless somebody comes with a better
>> solution.
>>
>> Of course, distros are free to add symlinks as Xlstopo then :)
> Xfoo is kinda reserved for X servers, not for X applications :)
>

Ok let's put a X server inside hwloc then.

Brice

Re: [hwloc-devel] lstopo-nox strikes back

[Samuel Thibault]

Brice Goglin, le Fri 27 Apr 2012 19:09:47 +0200, a écrit :
> Le 25/04/2012 15:42, Jiri Hladky a écrit :
> > I would vote to make lstopo ASCII only and introduce new GUI binary
> > "lstopo-gui" in the version 1.5
> 
> I'll commit that during the weekend unless somebody comes with a better
> solution.
> 
> Of course, distros are free to add symlinks as Xlstopo then :)

Xfoo is kinda reserved for X servers, not for X applications :)

Samuel

Re: [hwloc-devel] lstopo-nox strikes back

[Brice Goglin]

Le 25/04/2012 15:42, Jiri Hladky a écrit :
> I would vote to make lstopo ASCII only and introduce new GUI binary
> "lstopo-gui" in the version 1.5

I'll commit that during the weekend unless somebody comes with a better
solution.

Of course, distros are free to add symlinks as Xlstopo then :)

Brice

Re: [hwloc-devel] lstopo-nox strikes back

[Brice Goglin]

On 26/04/2012 08:11, Christopher Samuel wrote:

On 26/04/12 02:35, Brice Goglin wrote:


I think I would vote for lstopo (no X/cairo) and lstopo  so
that completion helps.

Not sure if that's an option with Debian given the policy; the hwloc
package would have to have lstopo with X enabled and then a nox
package would install that variant of lstopo and use the alternatives
system to select which to use.



lshw and lshw-gtk are co-installable on Debian and you get two different 
binaries without an alternative config. But that doesn't mean it's OK 
wrt the Debian policy :)


Brice

Re: [hwloc-devel] lstopo-nox strikes back

[Christopher Samuel]

On 26/04/12 02:35, Brice Goglin wrote:

> I think I would vote for lstopo (no X/cairo) and lstopo so
> that completion helps.

Not sure if that's an option with Debian given the policy; the hwloc
package would have to have lstopo with X enabled and then a nox
package would install that variant of lstopo and use the alternatives
system to select which to use.

cheers,
Chris
-- 
Christopher Samuel - Senior Systems Administrator
 VLSCI - Victorian Life Sciences Computation Initiative
 Email: sam...@unimelb.edu.au Phone: +61 (0)3 903 55545
 http://www.vlsci.unimelb.edu.au/

Re: [hwloc-devel] lstopo-nox strikes back

[Christopher Samuel]

On 25/04/12 23:44, Jeffrey Squyres wrote:

> FWIW: Having lstopo plugins for output would obviate the need for
> having two executable names.

IIRC that's generally handled via the alternatives system (or
diversions if you don't like alternatives) in Debian/Ubuntu.

-- 
Christopher Samuel - Senior Systems Administrator
 VLSCI - Victorian Life Sciences Computation Initiative
 Email: sam...@unimelb.edu.au Phone: +61 (0)3 903 55545
 http://www.vlsci.unimelb.edu.au/

Re: [hwloc-devel] lstopo-nox strikes back

[Guy Streeter]

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
environment.
--Guy

Re: [hwloc-devel] lstopo-nox strikes back

[Jeff Squyres]

On Apr 25, 2012, at 11:18 AM, Samuel Thibault wrote:

> But it still seems overkill to me to use approach 1 while approach 2
> just works.  Yes, that conflicts with the original issue of the thread.
> It happens that on Debian we can actually make hwloc and hwloc-nox
> co-installable, by just putting a diversion: the hwloc /usr/bin/lstopo
> would take over the hwloc-nox /usr/bin/lstopo.  Same command name, and
> installation flexibility.
> 
> Of course, my finding the whole thing overkill doesn't mean that I'm
> against it being done.  I'm just giving my point of view.


Fair enough.

Also, I fully recognize that I'm mainly a helper here -- you guys are 
definitely the main maintainers of hwloc.  So if my proposal is not preferred, 
I'll shut up about it.  :-)

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [hwloc-devel] lstopo-nox strikes back

[Samuel Thibault]

Jeff Squyres, le Wed 25 Apr 2012 17:11:28 +0200, a écrit :
> Yes: the lstopo user gets whatever the sysadmin chose to install.
> No: the system is not flexible for binary distributions
> 
> Meaning: I see 2 ways to have binary packages that have X/cairo support and 
> don't have X/cairo support:
> 
> 1. Have multiple, complimentary hwloc packages (i.e., they can both be 
> installed at the same time) that have different lstopo executable names
> 2. Have multiple, exclusionary hwloc packages that both use the same "lstopo" 
> executable name
> 
> My goal in the plugin suggestion is to have one lstopo executable but allow 
> multiple binary packages that can add or remove lstopo output support by 
> installing/removing plugins.

I fully understand that.

But it still seems overkill to me to use approach 1 while approach 2
just works.  Yes, that conflicts with the original issue of the thread.
It happens that on Debian we can actually make hwloc and hwloc-nox
co-installable, by just putting a diversion: the hwloc /usr/bin/lstopo
would take over the hwloc-nox /usr/bin/lstopo.  Same command name, and
installation flexibility.

Of course, my finding the whole thing overkill doesn't mean that I'm
against it being done.  I'm just giving my point of view.

Samuel

Re: [hwloc-devel] lstopo-nox strikes back

[Jeff Squyres]

On Apr 25, 2012, at 11:04 AM, Samuel Thibault wrote:

>> Yes, understood, but my point here is that there could be multiple hwloc 
>> packages -- one that installs the core and some base set of lstopo plugins 
>> (probably not cairo and X).  And then secondary packages install lstopo's 
>> cairo and X plugins.
>> 
>> Hence, a sysadmin can choose whether to have cairo/X support (because 
>> presumably they will both pull in bunches of dependencies).  
> 
> I understand that too.
> 
>> But the user always runs "lstopo" and gets the choice of whatever outputs 
>> the sysadmin has chosen to install.
> 
> Which is quite different from what you said above :)

Hmm.  Perhaps we're having a failure to communicate here.  :-(

> And it's what is already achieved by the current status.

Yes and no.

Yes: the lstopo user gets whatever the sysadmin chose to install.
No: the system is not flexible for binary distributions

Meaning: I see 2 ways to have binary packages that have X/cairo support and 
don't have X/cairo support:

1. Have multiple, complimentary hwloc packages (i.e., they can both be 
installed at the same time) that have different lstopo executable names
2. Have multiple, exclusionary hwloc packages that both use the same "lstopo" 
executable name

My goal in the plugin suggestion is to have one lstopo executable but allow 
multiple binary packages that can add or remove lstopo output support by 
installing/removing plugins.

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [hwloc-devel] lstopo-nox strikes back

[Samuel Thibault]

Jeff Squyres, le Wed 25 Apr 2012 17:03:01 +0200, a écrit :
> On Apr 25, 2012, at 10:58 AM, Samuel Thibault wrote:
> 
> > It already adapts itself, here.  The issue is that the user has to
> > install an X version to get potential for X support.  Which brings X.
> > If you do this with plugins, and you want automatic adaptation to
> > whether X is there, you'll have to install the plugin (it can't install
> > itself magically). And then that brings X too...
> 
> Yes, understood, but my point here is that there could be multiple hwloc 
> packages -- one that installs the core and some base set of lstopo plugins 
> (probably not cairo and X).  And then secondary packages install lstopo's 
> cairo and X plugins.
> 
> Hence, a sysadmin can choose whether to have cairo/X support (because 
> presumably they will both pull in bunches of dependencies).  

I understand that too.

> But the user always runs "lstopo" and gets the choice of whatever outputs the 
> sysadmin has chosen to install.

Which is quite different from what you said above :)
And it's what is already achieved by the current status.

> >> But if I'm in the minority, no problem...
> >> 
> >> If I'm not, I can work on a patch to see if it would be horribly 
> >> disruptive...
> > 
> > It would most probably not be, we already use a backend style, so it's a
> > matter of putting the code in separate plugins.
> 
> That was my assumption.  I am guessing/assuming that it's a matter of:
> 
> - adjusting configury to use libltdl
> - building the back-ends as DSOs, installing them

Yes.

> - adapting the back-ends to advertise their function pointers neutrally

They should be more or less already doing that.

> - adding a bit of dlopen-based logic to find/load all available backends

Yes.

Samuel

Re: [hwloc-devel] lstopo-nox strikes back

[Jeff Squyres]

On Apr 25, 2012, at 10:58 AM, Samuel Thibault wrote:

> It already adapts itself, here.  The issue is that the user has to
> install an X version to get potential for X support.  Which brings X.
> If you do this with plugins, and you want automatic adaptation to
> whether X is there, you'll have to install the plugin (it can't install
> itself magically). And then that brings X too...

Yes, understood, but my point here is that there could be multiple hwloc 
packages -- one that installs the core and some base set of lstopo plugins 
(probably not cairo and X).  And then secondary packages install lstopo's cairo 
and X plugins.

Hence, a sysadmin can choose whether to have cairo/X support (because 
presumably they will both pull in bunches of dependencies).  

But the user always runs "lstopo" and gets the choice of whatever outputs the 
sysadmin has chosen to install.

>> But if I'm in the minority, no problem...
>> 
>> If I'm not, I can work on a patch to see if it would be horribly 
>> disruptive...
> 
> It would most probably not be, we already use a backend style, so it's a
> matter of putting the code in separate plugins.


That was my assumption.  I am guessing/assuming that it's a matter of:

- adjusting configury to use libltdl
- building the back-ends as DSOs, installing them
- adapting the back-ends to advertise their function pointers neutrally
- adding a bit of dlopen-based logic to find/load all available backends

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [hwloc-devel] lstopo-nox strikes back

[Samuel Thibault]

Brice Goglin, le Wed 25 Apr 2012 16:58:16 +0200, a écrit :
> On 25/04/2012 16:55, Jeff Squyres wrote:
> >On Apr 25, 2012, at 10:48 AM, Samuel Thibault wrote:
> >
> >>>FWIW: Having lstopo plugins for output would obviate the need for having 
> >>>two executable names.
> >>Well, it seems overkill to me.  It makes sense to me to have both
> >>xlstopo and lstopo.
> >
> >Ick.  FWIW, I dislike having two executables.  I like having one executable 
> >that can adapt itself to whatever is loaded / available on the system.  :-)
> >
> >But if I'm in the minority, no problem...
> >
> >If I'm not, I can work on a patch to see if it would be horribly 
> >disruptive...
> >
> 
> FWIW, the plugin question may come back within a couple month because we'll
> have an intern looking at managing all backends better inside the hwloc
> core.

Well, that's not the same part of the code :) The core definitely needs
plugins, to support dynamic selection between linux & x86 detection, for
instance.

Samuel

Re: [hwloc-devel] lstopo-nox strikes back

[Samuel Thibault]

Jeff Squyres, le Wed 25 Apr 2012 16:55:23 +0200, a écrit :
> On Apr 25, 2012, at 10:48 AM, Samuel Thibault wrote:
> 
> >> FWIW: Having lstopo plugins for output would obviate the need for having 
> >> two executable names.
> > 
> > Well, it seems overkill to me.  It makes sense to me to have both
> > xlstopo and lstopo.
> 
> Ick.  FWIW, I dislike having two executables.  I like having one executable 
> that can adapt itself to whatever is loaded / available on the system.  :-)

It already adapts itself, here.  The issue is that the user has to
install an X version to get potential for X support.  Which brings X.
If you do this with plugins, and you want automatic adaptation to
whether X is there, you'll have to install the plugin (it can't install
itself magically). And then that brings X too...

> But if I'm in the minority, no problem...
> 
> If I'm not, I can work on a patch to see if it would be horribly disruptive...

It would most probably not be, we already use a backend style, so it's a
matter of putting the code in separate plugins.

Samuel

Re: [hwloc-devel] lstopo-nox strikes back

[Brice Goglin]

On 25/04/2012 16:55, Jeff Squyres wrote:

On Apr 25, 2012, at 10:48 AM, Samuel Thibault wrote:


FWIW: Having lstopo plugins for output would obviate the need for having two 
executable names.

Well, it seems overkill to me.  It makes sense to me to have both
xlstopo and lstopo.


Ick.  FWIW, I dislike having two executables.  I like having one executable 
that can adapt itself to whatever is loaded / available on the system.  :-)

But if I'm in the minority, no problem...

If I'm not, I can work on a patch to see if it would be horribly disruptive...



FWIW, the plugin question may come back within a couple month because 
we'll have an intern looking at managing all backends better inside the 
hwloc core.


Brice

Re: [hwloc-devel] lstopo-nox strikes back

[Jeff Squyres]

On Apr 25, 2012, at 10:48 AM, Samuel Thibault wrote:

>> FWIW: Having lstopo plugins for output would obviate the need for having two 
>> executable names.
> 
> Well, it seems overkill to me.  It makes sense to me to have both
> xlstopo and lstopo.


Ick.  FWIW, I dislike having two executables.  I like having one executable 
that can adapt itself to whatever is loaded / available on the system.  :-)

But if I'm in the minority, no problem...

If I'm not, I can work on a patch to see if it would be horribly disruptive...

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [hwloc-devel] lstopo-nox strikes back

[Jeffrey Squyres]

FWIW: Having lstopo plugins for output would obviate the need for having two 
executable names.


On Apr 25, 2012, at 9:42 AM, Jiri Hladky wrote:

> Hello,
> 
> I would strongly vote to split the hwloc package to the core (ASCII only, 
> including ASCII only version of lstopo ) package and GUI package which will 
> bring GUI version of lstopo. 
> 
> This is also the way how this is handled in Ubuntu - please check the packages
> vim - Vi IMproved - enhanced vi editor
> vim-gnome
> 
> vim-gnome depends on vim-common
> 
> I also believe that having two binaries of lstopo - similar to "vim" and 
> "gvim" will make the usage clear.
> 
> I would vote to make lstopo ASCII only and introduce new GUI binary 
> "lstopo-gui" in the version 1.5
> 
> Cheers
> Jirka
> 
> 
> 
> On Wed, Apr 25, 2012 at 2:13 PM, Chris Samuel  wrote:
> On Wednesday 25 April 2012 19:38:00 Brice Goglin wrote:
> 
> > How do people feel about this?
> 
> It sounds like what you have is a conflict between the policies of
> Debian (and hence Ubuntu) and the expectations of RHEL/CentOS users.
> 
> Debian Policy is fairly clear on this matter:
> 
> # 11.8.1 Providing X support and package priorities
> #
> # Programs that can be configured with support for the X Window System
> # must be configured to do so and must declare any package
> # dependencies necessary to satisfy their runtime requirements when
> # using the X Window System.  [...]
> 
> It says you can split it into a separate package to provide GUI
> functionality *only* if the "package is of higher priority than the X
> packages on which it depends" (which I suspect is not the usual case).
> 
> cheers,
> Chris
> --
>   Christopher Samuel - Senior Systems Administrator
>  VLSCI - Victorian Life Sciences Computation Initiative
>  Email: sam...@unimelb.edu.au Phone: +61 (0)3 903 55545
> http://www.vlsci.unimelb.edu.au/
> ___
> hwloc-devel mailing list
> hwloc-de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel
> 
> ___
> hwloc-devel mailing list
> hwloc-de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel


-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [hwloc-devel] lstopo-nox strikes back

[Chris Samuel]

On Wednesday 25 April 2012 19:38:00 Brice Goglin wrote:

> How do people feel about this? 

It sounds like what you have is a conflict between the policies of 
Debian (and hence Ubuntu) and the expectations of RHEL/CentOS users.

Debian Policy is fairly clear on this matter:

# 11.8.1 Providing X support and package priorities
#
# Programs that can be configured with support for the X Window System
# must be configured to do so and must declare any package
# dependencies necessary to satisfy their runtime requirements when
# using the X Window System.  [...]

It says you can split it into a separate package to provide GUI 
functionality *only* if the "package is of higher priority than the X 
packages on which it depends" (which I suspect is not the usual case).

cheers,
Chris
-- 
   Christopher Samuel - Senior Systems Administrator
 VLSCI - Victorian Life Sciences Computation Initiative
 Email: sam...@unimelb.edu.au Phone: +61 (0)3 903 55545
 http://www.vlsci.unimelb.edu.au/

Re: [hwloc-devel] lstopo-nox strikes back

[Ralph Castain]

I don't have a strong opinion, but the historical "standard practice" for 
Linux/Unix has always been to default to cmd line, non-graphical interfaces. 
Graphical output was optional. Of course, that stemmed from the days before 
everyone had a graphical display, but it is still generally followed.


On Apr 25, 2012, at 3: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
> 
> ___
> hwloc-devel mailing list
> hwloc-de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel