Bug#1023056: Bug#1014537: unnamed packaging files in a multibinary package should be an error
Hi Niels,
Niels Thykier wrote:
> I understand that you are unsatisfied with this proposal and that is
> fair.
Thanks.
> Though from my point of view, your email makes it hard for me to want to
> engage with you to find a solution that would (ideally) satisfy your desires
I'm sorry, but at that point I have to say the very same about your
previous e-mail. IMHO this is not a one-sided thing. See below for an
explanation.
> as well as solve the underlying problem that Steve wants to have
> solved.
Well, your proposal IMHO shoots wide of the mark and only leaves very
few room for discussion. (If you think, I'm totally wrong here, please
see below for a possibility where we might have misunderstood each
other.) Actually I was totally fine with what Steve requested.
Additionally, cloning bug reports for lintian and lintian-brush
already sounds very final, too. (Except for the mentioned, IMHO very
minor details around debian/README.Debian and debian/TODO, which IMHO
also overshoot.)
> Notably, nowhere in your email can I see any attempt from you to say
> "Could we find an alternative where single binary source packages
> can still leverage this short cut, because I find it very valuable?"
> in a neutral or constructive manner.
Mostly because Steve's suggestion was totally fine for me, just caring
about multi-binary packages and forbidding non-prefixed debhelper
files there. This makes sense!
Which is also why I haven't joined the discussion so far. His proposal
was sane and affects likely only a few packages where multi-binary
packages have non-prefixed debhelper files, which is bad thing and can
easily lead to barely visible packaging errors as with the case in
which he ran into initially. (Actually I ran into such issues in the
past, too, when switching single binary packages to multi-binary
packages. But even before Steve's bug report, I was generally aware of
that issue.)
But the proposal in your previous mail (at least as far as I
understand it even after reading it a second time) goes much farther
and wants to forbid non-prefixed debhelper files "generally".
And I read this "generally" as "for any package, single- as well as
multi-binary packages". And that's what I'm not happy with at all.
Maybe it was meant differently (if so, please elaborate), but that's
how I understand "generally". (And I know, we're both no native
English speakers, so any of us might be wrong here. That's something
which I indeed didn't take into account when I wrote that other mail
out of frustration.)
Additionally the phrase "I am open to not installing them
[debian/README.Debian, debian/TODO] by default if one of you are
willing to drive the discussion on debian-devel to assert there is
consensus for that." implies for me that there is no room for
discussion on any other part of your proposal.
> Instead, it feels to me like you are dumping your frustration on me
It _is_ frustration, that's very correct. Like on that chomping
changelog thingy which — as far as I can see — has only been discussed
on debian-devel (which I and probably many other DDs don't have time
to follow due its huge amount of traffic), but not in any debhelper
bug reports — which I do follow, because I have an interest in
debhelper and that it is cared about — nor has the discussion about it
announced on debian-devel-annoucne (which IMHO should be done for any
discussion on major changes in Debian's tool chain or central
packages).
> and have given up on working with me in solving the problem in the
> best way for all parties (including you!).
Not specifically on working with you as a person but with those who
currently drive the way in which debhelper moves. (Until recently I
was really glad that the policy strongly recommends the usage of
debhelper. In the meanwhile my opinion on this had changed. But you're
now on a good way to revert that. :-)
I though was — until now — a bit surprised about you seemingly not
being open for discussion. So I'm quite glad about your most recent
mail (the one I'm replying to now) which shows again the Niels I knew.
> I find emails like this super draining on my motivation. I have no
> interest in spending my volunteer time working with people that
> writing emails phrased such that they make me feel like that person
> has given up on me.
Yes, and my motivation to help with debhelper in case of something
happens (like what happened to lintian) has drained a lot recently,
too. If I would have been in Uploaders, I would have removed myself
from Uploaders after my previous mail.
> I ask that you rephrase your email in a way where I do not feel you have
> given up on working with me,
Oh, ok, so there's still more room for discussion than your last mail
suggested — and despite there are already bug reports against lintian
and lintian-brush?
So let's start! My suggestions ordered by my personal preference:
* Implement what Steve actually asked for and don't overshoot: Apply
the rules you've proposed solely for multi-binary packages and leave
the handling of single-binary as it is: No warnings, no rejections.
A lintian check can be done in addition to that warning, although I
see it's main purpose in doing statistics on that.
I currently imagine a classification-style lintian check with these
variants:
* no-debhelper-files
* single-binary-no-prefixes
* single-binary-prefixes
* single-binary-mixed
* multi-binary-no-prefixes-at-all
* multi-binary-no-prefixes-for-first-package
* multi-binary-mixed-for-first-package
* multi-binary-prefixes
(I hope I have covered all possible variants)
In addition we can issue a (single) warning for
* multi-binary-no-prefixes-at-all
* multi-binary-no-prefixes-for-first-package
* multi-binary-mixed-for-first-package
* single-binary-mixed
* Add a dh option to still allow non-prefixed debhelper files (and
scrap that idea of a lintian check for it as it IMHO would be very
redundant and unnecessarily complex and error-prone in case it has
to parse dh commandline options, too.)
* Writing a dh plugin which overrides the restrictions you proposed.
(This was actually my plan — as a third party plugin — until your
most recent mail on which I'm replying now. Given my work on
debhelper so far as well as having written one debhelper plugin, I
totally feel capable of writing such a plugin.)
> if you want me to engage any further with you. I hope we can agree
> on that minimum baseline for future communication.
Sure, but then please do the same and discuss such bold debhelper
changes first and also not just on debian-devel but at least also on
debhelper-devel or even better, in a debhelper bug report instead
making such a thing a fait accompli (fsck, I first wrote "fail
accompli" here — probably a Freudian typo :-) for those subscribed to
debhelper-devel. And please don't overshoot feature requests _and_
then present your proposal as fait accompli either, and encourage
discussion instead of sounding as if you want to suppress it.
Regards, Axel
--
,''`. | Axel Beckert <abe@debian.org>, https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`- | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Reply to: