Re: Bug#782543: ITP: gpaw -- DFT and beyond within the projector-augmented wave method

On Fri, Jul 10, 2015 at 9:51 PM, Michael Banck <mbanck@debian.org> wrote:

Hi,

On Fri, Jul 10, 2015 at 09:43:26PM +0200, Marcin Dulak wrote:
> On Fri, Jul 10, 2015 at 8:51 PM, Michael Banck <mbanck@debian.org> wrote:
> > On Fri, Jul 10, 2015 at 04:36:23PM +0200, Andreas Tille wrote:
> > > Apropos gpaw-setups: Since I can run `gbp buildpackage` in my clone her
> > > I did so but pbuilder was running into the following error:
> > >
> > > pbuilder-satisfydepends-dummy : Depends: gpaw-setups which is a
> > > virtual package.
> > >
> > > It seems you need to package gpaw-setups first if this is a
> > > build-dependency of gpaw. (BTW, please remove the ',' at the end
> > > of the last Build-Depends.)
> >
> > I assume those pseudopotentials are required to run the test suite?
> >
> > In that case, what we've been doing with other packages is just shipping
> > the minimum required data files to run the test cases as patches in the
> > Debian packaging, this might work for GPAW as well.
> >
> > That depends on course on how many different PPs the testsuite needs, if
> > the answer is "most of them", then yeah, Build-Depending on gpaw-setups
> > sounds ok.
>
> in my opinion the software should be shipped functional, i.e. the
> whole release of gpaw-setups.

I was talking about shipping the necessary pseudo-potentials for the
testsuite in the gpaw source (but not binary) package, and not
Build-Depending on gpaw-setups.

i see. That would require maintaining by the GPAW team a list of the potentials that are necessary for running the gpaw tests.

Alternatively if one tries to simply extract some selected potentials and include them in the gpaw source package

then at next gpaw upstream update one will have to go over the list of the extracted potentials and make sure
the new gpaw version uses the new/right ones.
This will generate manual work and room for mistakes for the maintainers but I don't see much gain from that.

Of course the separate gpaw-whatever data package would ship the whole
set.

That said, a more unified distribution-wide approach to
pseudo-potentials wouldn't hurt either, I have the feeling that quite a
few are duplicated amongst packages. But that is for another
discussion.

> > In any case, I think the binary package should just be called
> > "gpaw-data" in line with other scientific packages. It's fine to keep
> > the source package name as gpaw-setups, of course.
>
> let's keep gpaw-setups. This name is known to all the users of the program,

This is purely a package naming scheme issue, the users shouldn't need
to know about this, it should just work after running 'apt-get install
gpaw'.

that's my first package. I don't know what would be required to change the name

in the ITP and the git repository?

Marcin

> and gpaw-setups packaged under the same name on Fedora/CentOS.

There's lots of packages which are called differently in Debian and
Fedora so that isn't a valid point, either.

Michael