Re: OpenHPC on Debian
On Sun, 22 Jul 2018 at 00:50, Afif Elghraoui <afif@debian.org> wrote:
> If I understand correctly, you mean doing some of your work within
> Debian officially?
Hi Afif,
That's not entirely clear to me, yet.
Our RPM "release" works as an overlay to CentOS/OpenSuse that has
additional packages which do not belong to the original distro. More
or less like AUR, homebrew, ports.
Some of those packages may even conflict with the distro's own
packages (due to library and version dependencies), so we try not to
get that close.
For example, we have GCC 7.1 and GCC 7.1 compiled packages. Those are
clearly incompatible with CentOS' GCC 5.4 compiled packages. We also
have meta packages, that installs bundles and/or set environment
configurations, which may break existing Debian packages? (I'm
guessing here).
In that sense, Debian would be the wrong place to *have* those
packages. It would create too many conflict and make our lives harder
for little benefit.
But some of those packages already exist in the HPC group at Debian,
so if I start building my own packages that override yours, I'm bound
to create problems for both of us.
I can see a few scenarios:
1. Complement: I only build the packages that you don't have. This
would create the problem of releases coming out at different times and
would potentially conflict versions and build flags.
2. Segregate: I take the source packages you have, add my own and
build in house. This would inhibit potential collaboration between our
efforts.
3. Merge: We release the packages in Debian, trying to have the same
cadence of releases. This would complicate the release process on both
ends.
We could probably find a common ground, and use different strategies
for different package classes, but the more complex this is, the
harder it will be to maintain.
I'm fully aware how hard package maintenance is. :)
> Everyone is welcome to contribute, of course, and
> packages need to be sponsored by a Debian Developer, which entails a
> review for policy compliance.
That is the main reason for this email.
Even if I end up building everything, I still want a Debian developer
to have a look and help me be "as compliant as possible", in the case
we can't be compliant enough.
> The hard line is that we can include packages in the non-free section so
> long as the licenses permit redistribution. However, those packages are
> second-class citizens in that they are not autobuilt (if there's even
> source code) or tested with the archive QA tools.
This policy is similar to ours.
> I don't see a problem here either so long as we have people here that
> are willing to help out. I'm sure most of us here would agree that
> integrating your work into official Debian packages is a great idea, but
> volunteers tend to only package software if it's something they
> personally use.
We have a small user base and we usually only release what we can test.
We already add/update packages to our repos in that manner, but we
update close to 50% of our packages every few months.
If we are to have a Debian port, I would have to have the same thing
in our private repos, so not a big change to do that in Debian's own.
But it would (maybe) put pressure on your group to release more often
/ out-of-sync with your releases.
> I'd be willing to help people get started with making official Debian
> packages. If you have someone who is already working on the debs, maybe
> we can help them start with one that you want to integrate into Debian
> and get a process going.
Right now, there isn't anyone looking at this. I thought I'd first ask
around to make sure I start in the right direction.
I'll need to get sponsorship from Linaro (our steering committee) to
be able to spend time in this. If we get it approved, we'll be happy
to help maintain the packages.
> So what I'm offering is guidance, review, and sponsorship to get into
> the Debian archive, not that I'll do the additional packaging work and
> maintenance myself. Would that be useful to you?
Extremely.
I'm willing to do the maintenance and packaging for as long as it's
approved within Linaro, but I'd have to convince the rest of the
OpenHPC (and Debian HPC) communities to keep it up in case Linaro
drops support.
Given I can't control any of that, I'd rather start with a simple and
pragmatic approach and grow organically, than create a massive repo
and release schedule and then see that I'm the only one really
interested. :)
Maybe the first step would be to try installing an OpenHPC-like system
from our PDF and propose adding the missing packages to make it work.
They're obvious and usually interesting to have anyway.
If that works, and people start using, we can grow more. If not,
Debian HPC would have gained a few packages that can get validated
with Ansible.
thanks!
--renato
Reply to: