Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1122852 > unrolled thread

Bug#1014537: unnamed packaging files in a multibinary package should be an error

Back to article view | Back to linux.debian.bugs.dist

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#1014537: unnamed packaging files in a multibinary package should be an error Niels Thykier <niels@thykier.net> - 2022-10-29 21:20 +0200
    Bug#1014537: unnamed packaging files in a multibinary package should be an error Axel Beckert <abe@debian.org> - 2022-10-30 10:50 +0100
      Bug#1014537: unnamed packaging files in a multibinary package should be an error Niels Thykier <niels@thykier.net> - 2022-10-30 12:00 +0100
        Bug#1014537: unnamed packaging files in a multibinary package should be an error Axel Beckert <abe@debian.org> - 2022-10-30 18:00 +0100
          Bug#1014537: unnamed packaging files in a multibinary package should be an error Niels Thykier <niels@thykier.net> - 2022-11-05 13:00 +0100
    Bug#1014537: unnamed packaging files in a multibinary package should be an error Mattia Rizzolo <mattia@debian.org> - 2022-10-31 16:20 +0100

#1122852 — 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 <gregoa@debian.org> 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

[toc] | [next] | [standalone]

#1122936

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 <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

[toc] | [prev] | [next] | [standalone]

#1122948

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

[toc] | [prev] | [next] | [standalone]

#1122999

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

[toc] | [prev] | [next] | [standalone]

#1123689

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 I 
wanted to hear what other people said to my proposal.
   With you reading my email as final decision, it probably did not feel 
like I was opening the floor for discussion. However, that was my 
intention even though that sentiment failed to come across.

In your previous email, I feel you showed strong disagreement to my 
proposal and in this case I am happy to compromise on some of my 
priorities and go for an alternative solution.
   On a related note, I have updated my MR to match this compromise, 
where single binary packages are no longer affected by this change (at 
least as far as my testing shows - feel free to take it for spin and see 
if you can find any bugs related to that).


   At this point, I would like to stop here to ask whether you feel the
   conflict related to this bug has been resolved adequately?


I know we have not touched upon the changelog trimming and that 
definitely need a follow up.  If you agree that we have bridged the gap 
in this particular conflict, I hope you would be happy with me moving 
our discussion on the trimming of changelog conflict to #1014537 - for 
me this about keep relevant discussion in the bug/feature request that 
it relates to.

Best regards,
~Niels

[toc] | [prev] | [next] | [standalone]

#1123130

[Multipart message — attachments visible in raw view] — view raw

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  `-

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web