Bug#824900: RFS: iroffer-dinoex/3.30-1 [ITP]
> > > 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.
> What I've meant was "you replaced stronger default flag with a weaker
> one". As you know about dpkg-buildflags you should know that the 'fortify'
> option is enabled by default and that it adds -D_FORTIFY_SOURCE=2.
Didn't know that D_FORTIFY_SOURCE=2 was the default. Based on the manpage,
D_F_S=2 can break some programs, while D_F_S=1 should not. Given that there's
no real comprehensive tests, for iroffer-dinoex, I felt it was safer to set it
to 1 rather than 2.
> > It also gets rid of the lintian info tag
> > "hardening-no-fortify-functions".
> If you have this tag then something is wrong. If it's also fixed by adding
> -D_FORTIFY_SOURCE to CFLAGS then your upstream build system doesn't handle
> CPPFLAGS correctly. It should be fixed to handle them.
Until it's fixed upstream what is the "correct" way of getting it to compile
with -D_FORTIFY_SOURCE?
I've patched the configure script to accept external CPPFLAGS in the meantime.
> > > - 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?
> man dh_clean
> To remove files not removed by dh_auto_clean.
How handy. I've fixed the build to use debian/clean.
How do I get that documented in the maint-guide?
> > > - 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.
> Just Conflicts could be enough but it won't uninstall the other package.
> I don't know how Conflicts+Replaces will work, you'll need to test this.
> Note that you still won't be able to install iroffer without manually
> removing iroffer-dinoex (at least that's what I think).
What you described is what I intended the functionality to be. iroffer-dinoex
should be able to be installed _over_ iroffer (apt will remove the old package
automatically)
% sudo dpkg -i iroffer-dinoex_3.30-1_amd64.deb
Selecting previously unselected package iroffer-dinoex.
dpkg: considering removing iroffer in favour of iroffer-dinoex ...
dpkg: yes, will remove iroffer in favour of iroffer-dinoex
If you install iroffer over iroffer-dinoex, apt will prompt to remove
iroffer-dinoex before installing iroffer.
If this seems too far off what the norm is, I'm fine with removing the Replaces,
but based on the docs and my testing, this should be fine.
> > > 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.
> You seem to be confusing several things here.
> The upstream authors can do anything they want but the license clauses say
> what can other people do instead.
> "License: GPL-2" means "you can use GPL 2", "License: GPL-2+" means "you
> can use GPL 2 or (at your option) any later version".
> And the upstream LICENSE doesn't say about "any later version", so you
> didn't "leave it untouched".
> Actually, the upstream LICENSE includes the OpenSSL linking exception for
> some files and tells to look into the files to find out which of them have
> what licenses so your d/copyright should be more fine-grained than now.
>
> > > - 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/?
> Yes.
Fixed. Changed the license to BSD-3-clause.
> > no-upstream-changelog should be an I tag.
> Why do you think so?
That was my mistake. I got it mixed up with some other tags.
> > > - 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?
> The second option is preferable, note that the tag is W.
> But the first one is better than overriding it (you should override only
> things that are not problems, not things that are currently
> hard/impossible to fix problems)
Patched.
Regards,
Weilu
Reply to: