Re: [gentoo-alt] Re: [PREFIX] Bootstrap stable?

[Francois Bissey]

> On 4/04/2019, at 19:49, Fabian Groffen <grobian@g.o> wrote:
>
> Just chiming in on this interesting topic :)
>
> On 04-04-2019 01:51:58 +0000, Francois Bissey wrote:
>> Hi,
>>
>> As someone who was involved until very recently in installing software
>> on the New Zealand national facility I feel I should take exception to some
>> of these comments.
>> To put things in perspective
>> 1) I am using Gentoo since 2003
>> 2) I am a regular contributor to the science team and maintain sage-on-gentoo
>> 3) I pushed for a while to have prefix working on ppc64 (the hardware was
>> at some time part of the national facility above)
>> 4) I have contributed code to spack and help fix some issues with libtool
>> in spack and occasionally suggests fix to some packages.
>>
>> Gentoo prefix is awesome but some areas are not as flexible as spack.
>> Mainly because it is designed like a gentoo distro as a single tree
>> install. Everything goes into one prefix.
>> What spack allows you to do (and that is a usual requirement):
>> allow and maintain an unhealthy forest of softwares:
>> 1) across several versions
>> 2) across various compilers
>> The whole dynamically loadable via “modules”. Each bits in its own bubble.
>> This also has limitation of course.
>> Gentoo has slots that does multiple versions of some software but it is
>> not a universal feature (nor should it be on the point of view of a distro).
>> Basically if you want to reproduce some the scenarios managed by spack you
>> need multiple prefix.
>
> So what scenarios exactly are these?
>


It can be several versions of the same software as stated earlier. Either executable

or libraries.

For example while gromacs 5.x was stable a user wanted me to resurrect a copy of gromacs

3 something because it was the last version with a particular potential in the feature

set and that’s what they wanted to use.

You can have the same software compiled with different compilers. Which can be various

version of gcc/intel compilers or other proprietary compiler (PGI comes to mind as well

as cray which has its own toolchain). Because of potential incompatibilities in the 

Fortran binary interface you will have a tree by fortran compiler vendor and sometimes

different version of the same compiler (gcc 4 to 6, gcc 7 and gcc 8 all have a different

runtime want to troll bugzilla to see how many problems that created to users?).

People will want a particular compiler because the software they use compiled with

another compiler won’t pass the test suite or crash in their particular extreme 

scenario. And another group using the same software will want a different compiler for the

same reason.



Most HPC cluster will want MPI support. Which is fun to enable in prefix. Do you

go with the OFED stack from prefix or your vendor. Do you even have a choice 

(fortunately the scenario I was in with an old crummy 2.6 kernel is surely gone)?

If you go with your vendor you will have fun tweaking your prefix install.



> Things like multilib support?  We (at least I) stayed away from that
> feature in Prefix due to its added complexity.  I guess nowadays it
> could be reconsidered (profile change/addition?), even though some of
> the concepts are flawed, hence the preference for completely separate
> prefixes.


I don’t really care about multilib. The cases where I heard of someone

specifically wanting 32bits on a system defaulting to 64 can be counted

on one finger. Fun ticket that was, especially since they were also looking

at static linking in C++.

I would want multi-abi at the compiler level and more slotting with slot

change in the user environment. That would be a start.



I am sure one individual group or may be several group of people may find

a prefix interesting and even it bringing everything they need. But once

you start to interact with many groups at the national level who want 

completely different things it becomes impossible to fulfil all the

requirements with a single prefix.



There is a political aspect. Because HPC is hard to use, support does a lot

of software install for some standard or hard pieces - or some bits that

are deemed a priority. The other solution is to just give people the compilers

and tell them if you can’t hack it up yourself in your corner you don’t 

belong here.



François