Re: New package bali-phy
Hi Andreas,
On 03/08/2018 11:41 PM, Andreas Tille wrote:
Hi Benjamin,
thanks for packaging bali-phy which looks quite good. You even added
autopkgtest which is excellent work.
On Thu, Mar 08, 2018 at 05:44:59PM -0500, Benjamin Redelings wrote:
I've created a new project on salsa for the software 'bali-phy'. It
builds for me with gbp without any lintian warnings, and the installed
packages seem to work. Comments?
I've added pristine-tar as per policy[1], removed the redundant
debian/gbp.conf and changed the formatting of the d/control file
using `cme fix dpkg-control` to have some consistent formatting
between other Debian Med packages.
OK, I see, thanks. I had a local pristine-tar branch from gbp but I
guess I did not push it. I will fix up the local branch to point to the
remote branch.
I also added a spelling fix as quilt patch. I'm not always that picky
but since you are upstream you most probably want to fix this in your
code as well. Hint: If you are runnin lintian with -I option you get
also those issues.
Ah, it is nice to see an example quilt patch, and thanks for the advice
on lintian -I! Now I can see the error. I fixed the typo upstream, so I
guess we can remove the typo patch in the next release.
Something you might like to consider is the location of the examples
which is currently in /usr/share/bali-phy/examples. In Debian users are
used to check /usr/share/doc/PACKAGENAME/examples (no idea how many
users are *really* trained to look there - but at least this is the
recommended location). Moreover if we have some autopkgtest which is
providing some kind of example usage I tend to put this script as well
in this location and add a README.test that enables users on their local
machine to reproduce these tests as examples.
I wondered about this. I was unsure if /usr/share/doc/ is a good place
for non-Debian systems, so I did not change the upstream default. But
for Debian it is indeed the natural place for me to look. It seems
there are a few options:
1. Change upstream to install to /usr/share/doc/ everywhere
2. Edit meson.build to put the examples in /usr/share/doc/
3. #2 + make symlink to /usr/share/<package>/examples
4. Make a symlink from /usr/share/doc/<package>/examples to
/usr/share/<package>/examples
I'm not sure #1 works everywhere. #2 has the problem that the path to
the examples would be distribution-dependent. #3 and #4 both seem OK though.
Putting the autopkgtest scripts in the doc directory seems like a good
idea, as does adding a README.test . How do you get the test scripts
put in the doc directory, though?
Longer term, there is a more thorough testsuite in master/tests that I
use for upstream CI.
So far for the cosmetical things. There is one issue left which I would
like to discuss: In external/ dir there are code copies of Debian
packaged libraries. I noticed that you have added all those libraries
as Build-Depends and thus I assume the build is clean and is using the
Debian packaged versions. My way to deal with this kind of third party
software in upstream sources is to remove them completely from the
tarball. This has two advantages:
1. I can be *really* sure that the Debian packaged version is used
2. It saves me work from mentioning the stuff in d/copyright (which
can be quite complex some times)
If you agree with this approach I can do this for you as a simple
example since with Files-Excluded in d/copyright this is pretty easy
to do. In other words: The package is OK in principle and I could
upload as is. So if you prefer an untouched upstream tarball that
should be fine. But I personally would strip third party source and
if you want me to do this for you I can do before uploading.
I very much like the idea of stripping out these things, but I wasn't
sure how to do it. Do we do this with a quilt patch? Because that would
be a very large patch, and I didn't like the idea of removing the local
boost via a patch that was the same size as boost :-P But it is not
really important. Also, if we strip them out, do they still need to be
in the copyright file? That would shrink the copyright file nicely.
In addition, anything from the autotools build system can also be
removed. This includes:
m4/
configure.ac
bootstrap.sh
scripts/git_version.sh
$(find . -name Makefile.am)
Thanks again for your work on this
I'm glad to help. Thanks also for your help in cleaning up the packaging!
-BenRI
Reply to: