On Tue, Mar 27, 2018 at 11:09:51AM +0100, Simon McVittie wrote:
> 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.
Not necessarily through Debian's bpo infrastructure, but yes, I maintain
backports repos for both personal and company use for all of the still
supported distro releases (so for another month or so, all the way back
to oldoldstable). Not everything gets pushed into those, but since you
never can predict when something important might need to be, I usually
try pretty hard to ensure everything I'm responsible for can trivially
still be built out of the box on all of them.
And realistically, that's usually not very hard - all you have to do is
not gratuitously break things for older releases.
I'm certainly not the only one doing that, there's been plenty of
thank you's from people grateful it was trivial to do an unofficial
backport of things they've needed somewhere too.
> > > 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.
Sure, but none of those changes actually fixes a bug in this package,
so *at best*, changing the compat level will fix nothing, and hopefully
also break nothing, if I'm careful enough and have time enough to check
that none of the changes in behaviour actually do cause an unexpected
regression (which is quite common in packages where people do just
blindly bump the compat every time lintian or someone suggests they
should).
And really the main reason the currently deprecated set are deprecated
is just because Niels doesn't yet have an ideal way to keep adding new
compatibility levels indefinitely in a clean and easily maintainable
way. It's not because they are somehow fundamentally broken - at least
not if you don't need any of the things the newer compat levels add.
> Compat level 9, which is currently the oldest non-deprecated compat
> level, was available in what's now oldoldstable.
Yes, compat 9 is now my current baseline, for exactly that reason - but
that's not a change which warrants an upload to do only that. Not when
at best all it would do is not introduce a new bug. It will probably
happen with the next upload though - unless I need to do it in a hurry
and don't have time to properly regression test for a change like that.
> 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 it ever does, I actually *would* want this to break loudly and
obviously. So that we can assess whether the new dependency it
added was justifiable, or whether we should change something to
avoid it. For some packages more than others, I don't want to have
debhelper gratuitously adding new dependencies silently.
> 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).
It's documented here:
http://metadata.ftp-master.debian.org/changelogs/main/libo/libogg/libogg_1.3.2-1_copyright
I thought I'd actually reported a lintian bug about those being false
positives (many years ago now), but don't seem to see one still open
for that in the BTS ...
Maybe it was Simon Josefsson's check script, which at some point we
were using to test for these, which that happened for. Unless it was
fixed in lintian and then later regressed.
But either way, as a real false positive, it is lintian which should be
fixed here. Even that lintian tag itself says that is the correct action
for a false positive with this warning.
> > > 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.
It might seem like that would be ideal - but the reality is that when
they were first added here, the set of arch exclusions that dpkg (and
the hardening-wrapper package before it) used were themselves already
outdated and wrong. And they didn't enable it to be supported for
older releases. And at the time, many xiph projects were beginning
to add support for them to the upstream build systems so they they
didn't have to be added as an afterthought in distro specific hacks
for every distro. And that's before we get to the bit where some of
them can have subtle and/or undesirable side-effects - so we shouldn't
just be blindly changing them without testing, just because the package
was binNMU'd with a different version of dpkg available.
So I'm definitely interested in things that would really improve this,
but I don't think it's a slam dunk to say that blindly delegating that
to someone else who won't test what effect changes have on this code
would clearly be an improvement.
I appreciate that these also aren't answers which do scale to every
maintainer of every package we have - but I do want to be clear that
where some "one size fits all" rule of thumb isn't being followed
here, it's generally not because the options relating to that haven't
been considered previously with respect to their applicability here.
In the same way that not having an upload for 3 years isn't "neglect",
it simply wasn't broken in any way that needed fixing over that time.
I'm not sure why some people have such a hard time celebrating that
as an outstanding achievement. Software which isn't so broken that
it needs an upload every 2 weeks to fix the latest set of bugs is
what we should all be striving for - not worrying about! :)
Best,
Ron
