Re: Maintaining elmer packaging officially within Debian
[adding debian-science back in Cc]
على الإثنين 5 أيلول 2016 05:16، كتب Juhani Kataja:
> Hi Afif,
>
> good to hear. I'm still on it.
Great!
>
> How should I get started?
You should get setup to join the Debian Science team and access our Git
server.
This involves making an account on alioth.debian.org, setting up an ssh
key (see <https://wiki.debian.org/Alioth/SSH>), and requesting
membership to the Debian Science project:
<https://alioth.debian.org/projects/debian-science/>. Also, please
briefly review the team policy document:
<http://debian-science.alioth.debian.org/debian-science-policy.html>
>
> I'd propose following major about the package:
>
> * Divide it in two parts: ElmerGUI and ElmerSolver (containing binaries,
> shared libs and solver modules)
> * Install elmer shared libs under "lib/elmersolver" and equip elmer
> binaries with RPATH=$ORIGIN/../lib/elmersolver just like in the Ubuntu
> packages. Elmer comes with a patched version of arpack/parpack that will
> conflict with standard arpack/parpack.
> * Elmer installs solver modules (which are that shared libraries) under
> "share/elmersolver/lib", which is to my knowledge, deprecated
>
That looks like a good plan. There is a repository that was used for the
existing Debian packaging--actually two, with one for the documentation
package--but it is very old and it would be easier to rewrite many parts
of it like debian/rules.
https://anonscm.debian.org/cgit/debian-science/packages/elmerfem.git/
https://anonscm.debian.org/cgit/debian-science/packages/elmer-doc.git
> I would like to have the build rules (the "debian/" directory) in a
> public git repository that would neatly interact with the official elmer
> github repository.
>
> What kind of workflow/tools would you suggest for doing this?
If releases are reliably tagged in the upstream repository, as it
appears they are, we use debian/watch together with uscan(1) to track
and import new releases. We could arrange to package snapshots if
necessary, or specific commits can be applied as patches to the latest
release. We use gbp (from git-buildpackage) to manage the packaging
repository.
So to summarize and expand, I suggest the following direction (after
joining the team and setting up your ssh key as I mentioned at the
beginning):
* Clone the packaging repository. The following command will make sure
you track all the branches.
debcheckout -a --git-track="*" elmerfem
* Update debian/watch to point to the current upstream source and tag
format. See the uscan(1) manpage for exammples and documentation on the
format of debian/watch and how to use it.
After this, you can import the new sources and start on the repackaging.
I presume you are familiar with package development tools like sbuild or
pbuilder from your work on Ubuntu packaging. You would just need to make
sure you use a Debian Unstable chroot for development here.
Please feel free to ask questions if you get stuck.
Many thanks and regards
Afif
--
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name
Reply to: