On Tue, 27 Mar 2018 at 18:25:59 +1030, Ron wrote:
> On Mon, Mar 26, 2018 at 10:55:04PM +0100, Simon McVittie wrote:
> > lose the -dbg package,
>
> This would mean people wanting a backport to oldstable would lose easy
> access to debug symbols, so right now I'd still consider that to be a
> regression.
I've mostly considered a consistent interface to debug symbols across
packages within the same suite to be more important than backports to
oldstable-backports-sloppy, although I do see your point.
(stable is the source of official backports to oldstable-backports;
oldstable-backports-sloppy contains backports from testing, which can
break the upgrade path from oldstable to stable.)
Do you really backport the latest versions to oldstable or older? I tend
to think that if someone is sufficiently change-averse to be staying
with oldstable and not upgrading to stable, then installing backports
is the last thing they should be doing.
> > fix Lintian warnings,
>
> There are none which are flagging an actual problem in this package.
Debhelper compat levels > 5 fix bugs (or design flaws if you prefer) in
historical debhelper behaviour; the older compat levels are deprecated
for a reason. Tracking the latest isn't required, but I would recommend
catching up at least once per Debian stable cycle: that doesn't involve
a whole lot of uploads (about 1 per 2 years). Compat level 9, which
is currently the oldest non-deprecated compat level, was available in
what's now oldoldstable.
The absence of ${misc:Depends} might not be an issue now, but it could
become an actual problem, since it's where debhelper tools put new
dependencies as they become necessary.
If the RFCs are false-positives and they are actually Free Software,
please add Lintian overrides to document this for future contributors. If
they're non-free, then that's considered a release-critical bug (I can't
say I'm entirely convinced that applying the DFSG equally to documentation
is proportionate, but there have been GRs that say it's project consensus
that we do).
> > rebuilding with newer gcc defaults might well produce better-hardened
> > binaries.
>
> Do you have something specific in mind which might apply here beyond
> the current set of explicit hardening options this is built with?
I don't have anything specific in mind, but comparing what individual
packages do with the recommendations that dpkg-buildflags provides is
not something that can really scale to a project the size of Debian.
I notice that libogg has its own hard-coded knowledge of which hardening
flags work(ed in 2014) on which architectures. It seems like it would
be better to have this information exist centrally, in dpkg.
smcv
