Gromacs bump

[Christoph Junghans]

Hi,

I was holding back on packaging gromacs 2020 as it missed some essential
features, e.g. tabulated interactions, but now as gromacs 2021 is out and
the features are still missing, I am wondering if it is still reasonable to
hold back. The features are promised from gromacs 2022.

As many users still need the legacy features, I was thinking to fork
gromacs-2019 into a separate package, called "gromacs2019" or something,
and bump the normal gromacs package to v2021. Or do you guys have a better
idea?

Cheers,

Christoph

[Benson Muite]

On 2/4/21 6:54 AM, Christoph Junghans wrote:
> Hi,
>
> I was holding back on packaging gromacs 2020 as it missed some essential 
> features, e.g. tabulated interactions, but now as gromacs 2021 is out 
> and the features are still missing, I am wondering if it is still 
> reasonable to hold back. The features are promised from gromacs 2022.
>
> As many users still need the legacy features, I was thinking to fork 
> gromacs-2019 into a separate package, called "gromacs2019" or something, 
> and bump the normal gromacs package to v2021. Or do you guys have a 
> better idea?
>
> Cheers,
>
> Christoph

Maybe worth reaching out to GROMACS developers and perhaps also checking 
packaging for Debian/Ubuntu. That being said, performance gains from 
compiling GROMACS from source may be helpful. Would there then be 2 or 3 
GROMACS versions available for Fedora, 2021, 2020 and 2019? Would 
Flatpaks/Appimages be better for typical usecases?

[Christoph Junghans]

On Wed, Feb 3, 2021 at 11:07 PM Benson Muite  wrote:
> On 2/4/21 6:54 AM, Christoph Junghans wrote:
> > Hi,
> >
> > I was holding back on packaging gromacs 2020 as it missed some essential
> > features, e.g. tabulated interactions, but now as gromacs 2021 is out
> > and the features are still missing, I am wondering if it is still
> > reasonable to hold back. The features are promised from gromacs 2022.
> >
> > As many users still need the legacy features, I was thinking to fork
> > gromacs-2019 into a separate package, called "gromacs2019" or something,
> > and bump the normal gromacs package to v2021. Or do you guys have a
> > better idea?
> >
> > Cheers,
> >
> > Christoph
>
> Maybe worth reaching out to GROMACS developers and perhaps also checking
> packaging for Debian/Ubuntu. That being said, performance gains from
> compiling GROMACS from source may be helpful. Would there then be 2 or 3
> GROMACS versions available for Fedora, 2021, 2020 and 2019? Would
> Flatpaks/Appimages be better for typical usecases?

I have been talking to the gromacs devs and follow a couple of open
issues on their gitlab to be in the loop on the timeline for feature
to be back.
Debian moved to 2020 a while back, not sure if they were aware of the
missing features.

I think there is no point in keeping v2020 around if we package v2021,
so two versions max I guess.

Christoph
> scitech mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/[e-mail]...