Bug#824900: RFS: iroffer-dinoex/3.30-1 [ITP]
Hi Andrey,
Thanks for looking over this. I've replied to your concerns in line and
created a new build which (hopefully) addresses most of them.
> d/rules:
> - why -D_FORTIFY_SOURCE=1? Such things should be documented
For security reasons, as this is an internet accessible daemon that
accepts user input. It also gets rid of the lintian info tag
"hardening-no-fortify-functions". The docs for D_FORTIFY_SOURCE state it
won't break anything (compared to D_F_S=2). From my own testing, there's
no issues with the binary.
I've added a comment, and documented in Readme.debian (That is the
correct place to document, right?)
> - commented out -Wl,--as-needed looks strange, if it doesn't work/isn't
> needed you shouldn't include this line at all
> - "dh_make generated override targets" sounds strange. "This is example
> for Cmake (See https://bugs.debian.org/641051 )" sounds even strange,
> especially when looking at that bug. That commented out
> dh_auto_configure is strange too, especially the -DCMAKE_LIBRARY_PATH
> part.
These are all comments that came from the debian/rules template from
using dh_make (which is why they make no sense). I've removed them in the
latest build.
> - you can probably replace override_dh_auto_clean with debian/clean
I can't seem to find any documentation regarding debian/clean in the
maint-guide [https://www.debian.org/doc/manuals/maint-guide/dother.en.html]
How is debian/clean supposed to be used?
> README.source even says "You WILL either need to modify or delete this
> file"
Oops. Removed.
> d/control:
> - commented out Vcs-* fields should be either removed or uncommented and
> edited
Removed in the latest build.
> - why this package not only Conflicts but Replaces iroffer? Do you know
> how will apt handle this relationship? Do you intend to do anything with
> the iroffer package itself (it's orphaned ATM)? If you want to replace
> it completely then the replacing procedure is different, see
> https://wiki.debian.org/Renaming_a_Package
iroffer-dinoex is intended to be a drop-in replacement for the original
iroffer. The binaries have the same name, and the config formats are
unchanged.
Based on what I could tell from the docs (correct me if I'm wrong)
[www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces],
this is the correct way to have a package be an alternative drop in
replacement (ie how MTA's are managed).
I do not intend to take over the iroffer package completely. This is merely
an alternative to the original iroffer that can be a drop in
upgrade/replacement.
> d/copyright:
> - it says "GPL-2" and "LGPL-2.1" in the short names but "or (at your
> option) any later version" in the texts
I assumed "or (at your option) any later version" meant that the upstream
author could (at their discretion) upgrade the license to a newer version
of GPL. Not that an end-user (me) could upgrade to a newer version at my
descretion. I'm not a lawyer, so I chose to leave it untouched.
> - using GPL for debian/ while having MIT and LGPL in the upstream source
> is discouraged and may cause problems if debian/ contains e.g. patches
What's the correct way to resolve this, choose a less restrictive license
for debian/? Is there a list of recommended licenses?
> d/install is empty
Oops. I had used it for something prior and forgot to remove it.
Removed in the latest build.
> iroffer-dinoex.lintian-overrides:
> - you shouldn't override P tags
Which P tag did I override? no-upstream-changelog should be an I tag.
> - manpage-has-bad-whatis-entry override says "Upstream manpage" which
> doesn't sound like a valid cause to me
Should I just leave the lintian warning as-is until it's fixed upstream?
Or should I be patching the manpage until it's fixed upstream?
Thanks,
Weilu
Reply to: