Bug#841294: Overrule maintainer of "global" to package a new upstream version
On Wed, 19 Oct 2016 16:12:51 +0100, Wookey wrote:
> Indeed. The current situation is that the existing version is so old
> that it doesn't work properly with modern code any more, but the
> maintainer has refused to do any of:
> 1) upload a new package,
I'm not "refusing to upload a new package", I'm asserting that trading
one set of problems for a worse set of problems is not a solution to
a problem.
The crux of the problem is:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574947#131
And I don't think it's contentious to suggest that upstream's proposed
'solution' of using chmod 777 on a privileged directory is not something
that's acceptable for a distro package.
Shigio contacted me privately in 2010, proposing this mechanism as a
replacement for the interface that he and I first worked out in 1999
to do this securely in a way that was suitable for packaged software,
and I gave him a detailed review of that, explaining why that wasn't
a suitable answer, and what we'd need to do one way or another to make
it one. But he then simply ignored that (and later feigned ignorance
that we'd even discussed it - despite his own upstream changelog
acknowledging that we had), and made a series of incompatible changes
to do this anyway.
At around the same time, Taisuke Yamada had also expressed an interest
in this and tried to reason with him about sane ways to do this, but
his comments were similarly ignored as well.
I'd persisted with trying to find a common understanding that we could
base a real solution on, well past the point where the discussion had
become circular and repetitive, before ultimately becoming resigned to
the horrible stalemate which occurs when what you're arguing against
has devolved to a stubborn insistence that "your suggestion is not
simpler than chmod 777".
Until the discussion can move beyond that to recognise the problem,
our options were always going to be limited.
> 2) allow an upload which removes the offending CGI bit (which users
> don't really care about anyway)
If it was actually true that "users don't care about it", then it
shouldn't be a problem to get upstream to remove it.
But obviously that hasn't happened (or we wouldn't be having this
discussion), and when I last floated that option in one of the
re-runs of this, upstream outright rejected it too:
https://lists.debian.org/debian-project/2013/06/msg00174.html
The only thing he was interested in getting rid of was the option
to actually run this securely, with an audited system-wide script.
Not the parts where his own documentation and code comments say
things like "if you put this on the public internet, you lose", or
the part where he expects the CGI script must be installed in the
same tree as the rest of the generated page content.
It is true (in my opinion) that doxygen now does a much better job
of this than htags does, and that it would be no great loss (again
to me) for htags to just be killed completely if it can't be made
sane and safe. But I think it's a big stretch to claim that is
some sort of universal consensus, and that if we removed it, then
we wouldn't just end up right back here again with someone seeking
to override the maintainer to put it back, because it is essential
functionality to them, even if the people pleading here now don't
care about it.
htags is essentially useless without the CGI support, since that
is how it accesses the global tags to provide search and indexing.
You really would be far better off just using doxygen and its
search facility that doesn't require a CGI.
But someone cares about this, because doxygen itself got a patch
to let it use htags instead of its own source browser ... (whether
anyone actually uses that I'll leave as an exercise for someone
to research and report back to us on).
So if what you really want to do is kill htags completely, then
that's a discussion I'm willing to listen to, but it's going to
take some evidence of a genuinely stronger consensus than an
off the cuff "I don't care if we do that" - since you haven't so
far told us which bits you _do_ use and care about, so it's a bit
arbitrary to declare you, or some subset of what global currently
includes, more important than anyone else in a "rob peter to pay
paul" decision scenario.
> 3) write something to change the local behaviour to be satisfactory.
I wrote something to do this in 1999. The fundamental problem is
itself nearly old enough to drink in pubs. And I've maintained it for
as long as doing that was possible - but upstream has now gratuitously
broken the interfaces that we added back then (with his agreement and
collaboration and blessing) which enabled this to be done in a sane and
secure way - so the only alternative to nuking htags if upstream is
actively hostile to that now is to fork completely from upstream ...
which is essentially what has happened by sitting on the stable version
we currently have.
Yes, it sucks. But unless somebody else can convince Shigio, or
someone cares enough about adding new things to this to maintain
a sane fork that we can distribute and promote instead, then every
decision we might make from here will suck for someone.
I've said (more than once to various people), that I'd take patches
to add or fix things people needed to cover for other incompatible
changes upstream has made which break other things too
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574947#166
... but so far, nobody seems interested in spending anything more
than someone else's time on investigating and fixing that either.
> Upstream has been clear that they are not going to change how it
> works, but they don't care if debian omits that bit or changes it
> locally,
[citation needed]
I'm not aware of anywhere that upstream has said he is ok with us
dropping htags or its supporting CGI. Only with dropping support
for providing it securely in a system CGI directory ...
I think you might be extrapolating from ambiguous (and yes, sometimes
outright conflicting) statements on this, which apparently don't
actually mean what we might have hoped they'd mean. But he appeared
to clarify this in the negative in his most recent comments to that
-project thread.
If you're looking at something different to that, then please point,
but I suspect this has become a chinese whisper that people here are
repeating now, not something upstream actually said or believes.
> so it seems to me that a maintainer has to do one of the
> above three things. 5 years of this is more than long enough to
> conclude that they are not doing their job adequately, and because of
> our strong maintainership culture, are preventing other people from
> doing that job.
Which part of our strong culture is the one that prevents people
from actually acknowledging that Hard Problems Are Hard? And that
they are even harder when all you do is complain that somebody else
didn't fix them for you already.
Nobody has been prevented from sending a patch that would fix any
actual problem they are having because of the version we currently
ship. And of course, nobody has actually ever sent such a patch
either. They haven't even actually gone so far as clearly identifying
any actual problem they had beyond saying something along the lines of
"some stuff seems not to work, I didn't investigate further" ...
If your complaint is that "somebody who understands the problem has
raised reasoned objections to somebody who doesn't uploading something
that isn't suitable for inclusion in the distro" - then I'd call that
a ringing endorsement of having delegated and responsible maintainers
to shepherd such things.
That doesn't remove the ability of other people to also actually
contribute to trying to solve hard problems, in some more substantial
way than saying "just close your eyes and upload it anyway".
> It could just be NMUed, or a global6 uploaded so at least people would
> have something to work with, but asking the TC to rule seems like a
> more correct way to try and unbung this situation.
Yes, I think a discussion here is probably more useful and helpful than
the chaos and harm of ignoring the problems and uploading it anyway.
I can't help the ghost of Angry Ian if he wants to prejudge things and
try to play passive-aggressive mind-games with the actual TC delegates
without actually bothering to read what was already discussed many times,
but I am sympathetic to the people who currently feel like they have the
short straw and are on the wrong side of the pain caused by the current
situation.
I'm also sympathetic to the other people who you'd be handing that
hot potato to by asserting your problem is more important than
theirs. I am the one stuck in the middle feeling everyone's pain
here, so I have more motivation than all of you for finding a good
and lasting solution :)
So I think you probably need to clarify what you are really asking
for here, since the original question as put to the -ctte glosses
over a big bag of implications and consequences.
It seems fair to assume that you aren't seriously asking them to
endorse the idea of chmod 777 as an acceptable interface for
distro software - but that's what "force the new version into
the distro one way or another" actually means.
So are you asking if we should package a version that has htags
removed instead of what we currently have? Because that's the
essential implication of "remove the offending CGI bit".
Or are you asking if we should somehow fix the incompatibility
with "many frontends", that nobody has explicitly detailed or
reported yet. Because that's a possibility too, though arguably
it's actually a bug in the "many frontends" and/or another fatal
flaw in the upstream maintenance of this software that it keeps
breaking compatibility by changing the meaning of existing options
and renaming them gratuitously.
Or something else entirely?
When all you ask me is "upload global6 or else", there's not much
I can usefully discuss except to repeat facts I've repeated many
times before that still haven't changed. If you can acknowledge
the problems with that, including the ones it would make for other
people which you don't personally care about, then we can try to
find some consensus on what a good way forward might be ... and
point to that the next time someone asks "what needs to be done
to fix this?". But that's hard to do when people are just tugging
hard in some direction solely on their own self interest.
I want a good solution to this at least as much as anyone else does,
but the path of least resistance is what makes a river crooked, so if
we don't want this to end up as some sort of bug infested billabong
spreading disease to the people who use it, then we will need some
better answers than just "blindly package and upload a new upstream
version" - because the minimal work needed to do just that is not the
actual problem here.
Cheers,
Ron
Reply to: