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?

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.

Thanks,
Fabian

> That’s not to say spack wouldn’t benefit from a dose of gentoo and vice versa.
> But some Gentoo features have been voluntarily avoided :(
> 
> Now prefix was very useful to me to offer a base userland on top of SLES 11.1
> (which couldn’t be updated for various reasons) that was much more recent and
> feature-full than I would otherwise have had access too. And then I could put 
> something like spack on top if I wanted to.
> 
> François
> 
> > On 4/04/2019, at 07:57, Guilherme Amadio <[email protected]> wrote:
> > 
> > Hi Jon,
> > 
> >> On 3 Apr 2019, at 12:56, Jon Woodring <[email protected]> wrote:
> >> 
> >> Looking at the GSOC, I noticed that it’s mentioned that one of Prefix’s 
> >> goals is to bring Gentoo to HPC, and actually that’s where I was trying to 
> >> use Prefix.
> >> 
> >> I don’t know if you’re familiar with Spack https://spack.io/, but I was 
> >> exploring using Prefix and portage, because it has a larger community and 
> >> more features.
> > 
> > Yes, I’m advocating for using prefix for HEP (at CERN) and HPC in the HSF 
> > packaging group,
> > but I think that they are unfortunately more interested in using spack, 
> > even though it
> > doesn’t seem to be mature enough for what is its intended use. In any case, 
> > since you are
> > from LANL, if your cluster has CVMFS mounted (i.e. /cvmfs/sft.cern.ch), 
> > then you can already
> > use prefix! I have prefix installed in CVMFS, which I discussed at CHEP:
> > https://indico.cern.ch/event/587955/contributions/2938043/
> > 
> > Just run /cvmfs/sft.cern.ch/lcg/contrib/gentoo/linux/x86_64/startprefix to 
> > get started.
> > 
> > In principle, there’s nothing preventing you from using 
> > ACCEPT_KEYWORDS=‘x86_64’ in your
> > prefix configuration. It’s just not tried by anyone yet. We all use ~x86_64 
> > for now for
> > prefix on Linux. On Mac OS X there’s no stable keyword, ~*-macos are the 
> > only ones.
> > 
> > My first talk about prefix for HSF packaging group:
> > https://indico.cern.ch/event/672745/
> > 
> > Other related links:
> > https://hepsoftwarefoundation.org/workinggroups/packaging.html
> > https://groups.google.com/forum/#!forum/hsf-packaging-wg
> > https://indico.cern.ch/category/7975/
> > 
> > Cheers,
> > -Guilherme
> 

-- 
Fabian Groffen
Gentoo on a different level

Attachment: signature.asc
Description: PGP signature

Reply via email to