Bug#1014537: unnamed packaging files in a multibinary package should be an error
Control: tags 1023056 moreinfo
Control: tags 1023057 moreinfo
Axel Beckert:
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.
> [...]
Hi Axel,
First off, thanks for your reply. I very much appreciate you reaching
out here and putting your concerns forward as that enables to find
common ground and work on resolving the conflict. :)
Also, sorry for the late reply. My "post-work" mental bandwidth this
week has not enabled me to have adequate capacity for my follow up until
now.
As for your concerns, I have read them and I feel that we have two
conflicts that have been entangled into one. Therefore, I would like to
first attempt to untangle them and solve them separately. As I see it,
the current conflict is this bug (#1014537) but there is also the
initial conflict related to the changelog trimming.
As I understood you, your issues are - *for this bug specifically*:
1) You feel that I have made a final decision. Here you mention the
cloning of bug and the debian/{TODO,README.Debian} as two things
that made you feel the decision to be final.
2) While you agreed with Steve's feature request you did not feel my
proposed solution to Steve's request matched what you had expected
of me.
- For completeness, it is a bit unclear to me whether you also feel
this ties in to point about changes not being discussed on the
proper channel. It is possible for me to see narrative that given
you also felt the proposal was a final decision - but maybe I am
over reading you here.
3) Current frustration with the changelog trimming. I think a very
quick summary is that you feel changelog trimming proposal was not
discussed on the proper channels and also you strongly disagree with
the concept itself.
- Note I am deliberately keeping this short because I understand it
as an existing source of frustration caused by a different
conflict. Notably, this is the separate conflict I want to
untangle from the current one about unnamed packaging files.
However, since you explicitly brought the frustration caused by
that conflict, I felt the summary would be incomplete without
mentioning this part as well.
I hope you feel that is an accurate summary of the conflict related to
*this* bug about unnamed packaging files in multi-binary packages.
If you do *not* feel it was a good summary, then please stop reading
more of this email and tell me where I misunderstood or misread you.
The rest of my email is based on the above being a reasonably accurate
understand of the conflict. If I missed the mark on understanding
you, the rest of the email will probably just feel like an aggravating
straw man discussion to you and that is not what either of us want.
In a face to face discussion, I would normally wait for you to confirm
that my summary was good enough. However, I am going to risk optimizing
a bit by reducing the number of email round trips because I suspect the
conflict related to this bug will be easy to resolve.
=> Again, if you felt I misread you above, please stop here and tell
me where I was wrong.
I would like to start by addressing the part where you felt I made a
final decision. My previous email was *not* intended to be a final
decision. It was my request for feedback on my proposed solution.
Diving a bit deeper in what I intended with the actions you mentioned as
making it feel like a final decision:
* The cloned bug was me noting gregor suggesting a lintian tag for this
and me thinking "let me just do it immediately, so I do not forget".
Admittedly, the bugs should probably have been tagged moreinfo as
well because the actual requested change had not (and is still not)
fleshed out yet. I have done this now.
* My mention of debian/{TODO,README.Debian} was related to the part
where I was leaving these files as exceptions to Steve's request. If
Steve (or someone else) wanted this particular exception "undone", I
wanted that person to drive the discussion to show there was
consensus for that change.
I hope the above clarified my actions and made it clear that I never
intended this to be a "final decision".
As for my proposal not being what you had expected. My intention with
the email was to discuss my proposed solution. We all have different
priorities and I made my proposal in a way I felt were aligned with the
original proposal while also helping me with some of my priorities.
However, I was aware that it was a potential controversial point, so
Bug#1014537: unnamed packaging files in a multibinary package should be an error
Hi Niels, Thank you for this work. Personally I have only one point I'd like to raise: On Sat, Oct 29, 2022 at 08:55:38PM +0200, Niels Thykier wrote: > * debian/README.Debian > * debian/TODO > > These have historically been installed into the main package and a note in > debhelper (dh_installdocs) suggests these (or at least README.Debian) is a > name standardized by Policy. I am open to not installing them by default if > one of you are willing to drive the discussion on debian-devel to assert > there is consensus for that. In all my QA work around the archive (admittedly, not much in the last few years), I don't think I ever saw *one* d/TODO file that was up-to-date; they always felt remnants from the last century or so. Also, IIRC most of the time those files contained TODO items for the maintainer, something that is hardly interesting for the final user. Do you have any number about this file? As such, I'd like to propose to instead not ship this file by default if present in the source package. BTW, is d/TODO documented anywhere? I know it's an historic file, but I don't think I saw it mentioned in any formal document. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
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
Bug#1014537: unnamed packaging files in a multibinary package should be an error
Axel Beckert: Hi, I am looking at making `debian/foo` an error by default in debhelper compat 15 (triggering a warning from compat 14). Uargh, yet another bad decision which makes one want to no more using debhelper. :-( Hi Axel, I understand that you are unsatisfied with this proposal and that is fair. 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 as well as solve the underlying problem that Steve wants to have solved. 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. Instead, it feels to me like you are dumping your frustration on me and have given up on working with me in solving the problem in the best way for all parties (including you!). 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. I ask that you rephrase your email in a way where I do not feel you have given up on working with me, if you want me to engage any further with you. I hope we can agree on that minimum baseline for future communication. ~Niels
Bug#1014537: unnamed packaging files in a multibinary package should be an error
Hi,
> I am looking at making `debian/foo` an error by default in debhelper compat
> 15 (triggering a warning from compat 14).
Uargh, yet another bad decision which makes one want to no more using
debhelper. :-(
> > > This kind of packaging, with some packaging files under debian/ having an
> > > associated binary package name and some not, is an antipattern.
> >
> > +1
-1
> > (I also don't like packaging files without binary package name for
> > single-binary source package, but that's just a matter of taste.)
Exactly. I find it a very annoying nuisance to have to do that for
single binary packages.
> These have historically applied to all packages and it does not seem useful
> to force everyone to maintain N copies of {changelog,copyright,...}.
It also would probably violate the policy with regards to source packages.
> I have CC'ed lintian + lintian-brush on CC and cloned bugs for them. Having
> a lintian tag for them will enable the Janitor to help with the migration,
> so I agree we should have a lintian tag for this.
*sigh*
Regards, Axel
--
,''`. | Axel Beckert , 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
Bug#1014537: unnamed packaging files in a multibinary package should be an error
Control: clone -1 -2 -3
Control: reassign -2 lintian
Control: reassign -3 lintian-brush
Control: block -3 by -2
Control: block -3 by -1
Control: block -2 by -1
Hi,
CC'ing relevant maintainers for clone + reassign for lintian +
lintian-brush.
I am looking at making `debian/foo` an error by default in debhelper
compat 15 (triggering a warning from compat 14). The choice of having
an intermediate compat level is to align the change with another
"single-binary vs. multi-binary" change.
My current code proposal is at
https://salsa.debian.org/debian/debhelper/-/merge_requests/97 for people
who are curious or want to help by testing.
@Michael: This has some interesting affects on the
dh_installsystemd{,user} test cases. Could you have a look at
dh_installsystemd{,user} and see if you agree with where this is headed
for that helper? If it is becoming unslightly, maybe we should combine
it with a fix for #932152.
On Sat, 9 Jul 2022 00:11:47 +0200 gregor herrmann wrote:
On Thu, 07 Jul 2022 08:48:36 -0700, Steve Langasek wrote:
> This kind of packaging, with some packaging files under debian/ having an
> associated binary package name and some not, is an antipattern.
+1
(I also don't like packaging files without binary package name for
single-binary source package, but that's just a matter of taste.)
I will standardize forbidding `debian/foo` in the general case with the
following exceptions:
* debian/copyright
* debian/changelog
* debian/NEWS
These have historically applied to all packages and it does not seem
useful to force everyone to maintain N copies of {changelog,copyright,...}.
* debian/README.Debian
* debian/TODO
These have historically been installed into the main package and a note
in debhelper (dh_installdocs) suggests these (or at least README.Debian)
is a name standardized by Policy. I am open to not installing them by
default if one of you are willing to drive the discussion on
debian-devel to assert there is consensus for that.
Otherwise, I will keep the special-case for these two files for now.
> I would like to suggest that in the next debhelper compat level, debhelper
> should consider it an error when debian/control lists more than one binary
> package, but contains unnamed packaging files under debian/.
Or maybe start with a warning (maybe immediately) and then proceed to
an error?
I also wonder if a lintian warning might be helpful to get this
going.
(And I admit that I haven't checked if such a lintian tag exists but
I can't remember seeing one.)
Cheers,
gregor
[...]
I have CC'ed lintian + lintian-brush on CC and cloned bugs for them.
Having a lintian tag for them will enable the Janitor to help with the
migration, so I agree we should have a lintian tag for this.
Thanks,
~Niels
Bug#1014537: unnamed packaging files in a multibinary package should be an error
On Sun, Aug 14, 2022 at 03:55:05PM +0200, Chris Hofstaedtler wrote:
> * gregor herrmann [220814 13:53]:
> > On Thu, 07 Jul 2022 08:48:36 -0700, Steve Langasek wrote:
> > > This kind of packaging, with some packaging files under debian/ having an
> > > associated binary package name and some not, is an antipattern.
> > +1
> [..]
> > > I would like to suggest that in the next debhelper compat level, debhelper
> > > should consider it an error when debian/control lists more than one binary
> > > package, but contains unnamed packaging files under debian/.
> When I read this initially, I thought this would be a very good
> idea. Then I came across the usage of `bug-script` in
> src:multipath-tools. It wants to install the reportbug helper into
> all debs - quite reasonable I would say.
> Not sure if the proposed rule can be generalised enough...
I think what you describe is quite reasonable, but I fail to see what it has
to do with this bug report. multipath-tools has the following code in
debian/rules:
for pkg in "multipath-tools" "multipath-tools-boot"; do \
install -D -m 755 debian/reportbug/script
debian/$${pkg}/usr/share/bug/$${pkg}/script; \
done
That code is unaffected by the changes suggested in this bug. And a bare
'debian/install' file would not help at all in achieving this. Files listed
in debian/install would NOT be installed in all packages; in fact,
debian/install would be ignored in favor of the already-present
debian/multipath-tools.install.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: PGP signature
Bug#1014537: unnamed packaging files in a multibinary package should be an error
* gregor herrmann [220814 13:53]: > On Thu, 07 Jul 2022 08:48:36 -0700, Steve Langasek wrote: > > > This kind of packaging, with some packaging files under debian/ having an > > associated binary package name and some not, is an antipattern. > > +1 [..] > > I would like to suggest that in the next debhelper compat level, debhelper > > should consider it an error when debian/control lists more than one binary > > package, but contains unnamed packaging files under debian/. When I read this initially, I thought this would be a very good idea. Then I came across the usage of `bug-script` in src:multipath-tools. It wants to install the reportbug helper into all debs - quite reasonable I would say. Not sure if the proposed rule can be generalised enough... Chris
Bug#1014537: unnamed packaging files in a multibinary package should be an error
On Thu, 07 Jul 2022 08:48:36 -0700, Steve Langasek wrote: > This kind of packaging, with some packaging files under debian/ having an > associated binary package name and some not, is an antipattern. +1 (I also don't like packaging files without binary package name for single-binary source package, but that's just a matter of taste.) > I would like to suggest that in the next debhelper compat level, debhelper > should consider it an error when debian/control lists more than one binary > package, but contains unnamed packaging files under debian/. Or maybe start with a warning (maybe immediately) and then proceed to an error? I also wonder if a lintian warning might be helpful to get this going. (And I admit that I haven't checked if such a lintian tag exists but I can't remember seeing one.) Cheers, gregor -- .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe `- signature.asc Description: Digital Signature
Bug#1014537: unnamed packaging files in a multibinary package should be an error
Package: debhelper Version: 13.8 Severity: wishlist User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu kinetic Hi Niels, I was recently doing work on a package where, for $reasons, I was deleting a binary package from debian/control. This had very bad side effects, because the debian/ directory for this package contained debian/dirs, debian/install, and debian/postinst; and the package I was deleting from debian/control was the first listed; so the consequence of this change was that debhelper was suddenly applying these files to the next binary package in debian/control, with very incorrect effects. This kind of packaging, with some packaging files under debian/ having an associated binary package name and some not, is an antipattern. I would like to suggest that in the next debhelper compat level, debhelper should consider it an error when debian/control lists more than one binary package, but contains unnamed packaging files under debian/. This of course would only solve this particular class of bug for packages that update to the current debhelper compat level, and changing debian/control to remove (or reorder) binary packages is an infrequent operation; nevertheless this seems worth doing IMHO. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
