Re: FEniCS still on SVN?
On Sat, 2016-04-23 at 21:26 +0000, Mattia Rizzolo wrote:
> On Sat, Apr 23, 2016 at 02:37:19PM +0800, Drew Parsons wrote:
> >
> > It'd suit me well to host it on git. I'm familiar with git but
> > have to
> > track down the right svn commands each time, which slows down
> > maintenance.
> hoping this improve the quality of the packages (as at least dolfin
> and
> fenics (this one only because it's a rdep of dolfin) are on our black
> list of packages causing troubles to use trying to remove
> libpng12/vtk5/itk3/... from the archive), I've done it.
>
> https://anonscm.debian.org/git/debian-science/packages/fenics
>
> These are ok:
> dolfin
> ffc
> fiat
> instant
> ufl
Thanks Mattia, the repos look good.
The fenics "package" is a dummy package pulling the suite in. It might
be more efficient to create it as a dummy package in dolfin rather than
keeping a separate repo for it. It's a question of taste I guess.
> ferari
...
> syfi
> ufc
> viper
These (and uflacs) are deprecated. Actually I don't know what syfi is,
it's not a current FENiCS package upstream. Precursor to ufc maybe,
which was a precursor to ffc. Likewise viper isn't FENiCS upstream now.
I'm in favour of leaving them in svn so they don't get us confused.
> These instead had directories on the svn repo, and there is some
> basic
> packaging, but they are not uploaded, and as so, I couldn't import
> the
> upstream tarball.
> mshr
Yeah, we should get mshr operational.
>
> also consider that due to the way svn-buildpackage works, the debian
> tags are not in the master branch, but if you have some of what I
> personally call basic knowledge of git it won't be a issue :)
>
> Now, for all of those packages, it wouldn't seriously harm doing an
> uploads cleaning them up a bit and whatnot (several of them are out
> of
> testing due to RC bugs, etc...), and changing Vcs-Git.
I can clean up the current core packages (apart from mshr). The
deprecated ones can bitrot :)
I want to set the petsc-dev dependency in dolfin to petsc3.6-dev.
python-dolfin calls on petsc-dev at execution (the dolfin scripts are
like "just-in-time" interpreted scripts), so I think the petsc invoked
at runtime should be consistent with the one that libdolfin1.6 is
compiled against (currently petsc3.6). i.e. I think we want ABI
consistency. Otherwise we could be in a position where petsc3.8 is
pulled in at runtime while libdolfin1.6 still uses petsc3.6.
Drew
Reply to: