Re: 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
Reply to: