Bug#1077938: lintian: Fails to emit `debian-build-system` for packages not using `debian/rules`
Nilesh Patra:
Hi Niels,
Thank you so much for such a detailed response!
No problem. :)
[...]
I have a question here:
Since "Build-Driver: debputy" will actually be used in full integration mode,
does
it need a (mandatory) Build-Depends on debputy?
If so, should I add a tag with error severity if this is missing?
As you noted, it is technically true, but not testable by lintian.
Also, I believe I can generally assume if full integration mode is used, these
tags
are not relevant.
Ok, sounds reasonable.
- python3-depends-but-no-python3-helper
This one is complicated. Right now `debputy` does not support the python
tooling, so if you had `${python3:Depends}` with `Build-Driver:
debputy`, it would be a mistake.
However, `debputy` will complain loudly about this during migration when
it spots the tooling (it reacts to `dh-sequence-python3` as no go and
`override` targets as requiring manual intervention), so I do not think
it will be relevant in practice. Finally, once `debputy` support this
and a package migrates, then due to #1067653 they can just remove the
`${pthon3:Depends}` (to hide the warning).
I think you should implement what is easiest for lintian right now on
this one.
Related, I think this tag will "disappear" over time due to #1067653.
For now, lintian will just skip over this tag in full integration mode.
We can re-visit this later when debputy adds support for python.
Ok. :)
3. On what conditions should "package-does-not-use-debhelper" be emitted when
Build-Driver is debputy?
I would say, never. The package is using a package helper, which I
believe is the point of that tag.
The official project decision is still that `dh` is the preferred. So
the tag about not using `dh` should probably still be emitted (as I
recall, that is a different tag).
I disagree with the tag and likely so does any maintainer of the
packages with `Build-Driver: debputy` since they migrated. However, I do
not feel that `debputy` is used widely enough that it would make sense
to challenge the project stance on the prefer package helper(s).
Therefore, `lintian` should still expect the current project consensus
on that matter.
Okay, so whenever a package does not use debhelper, which is always assumed for
now whenever things
run in full integration mode, this pedantic tag will be emitted.
In some sense, this will be a false positive if debhelper is used somewhere in
the process, but given
that main build-driver is debputy, it probably makes sense to emit this until
project consensus shifts.
Ok with me. :)
[...]
I hope this answered your questions, and thanks for working on this. :)
I have one question for you to answer above.
And I have opened a MR implementing Build-Driver changes. May I ask you to
review and let me know
if you see any false positives, or anything else that I should fix?
That'd be very helpful. MR:
https://salsa.debian.org/lintian/lintian/-/merge_requests/697
Best,
Nilesh
Thanks, it looks good to me. :)
I am looking forward to getting `debputy` into the stats on trends.d.n. :)
Best regards,
Niels
OpenPGP_signature.asc
Description: OpenPGP digital signature
Bug#1077938: lintian: Fails to emit `debian-build-system` for packages not using `debian/rules`
Hi Niels,
Thank you so much for such a detailed response!
On 11/04/26 3:13 pm, Niels Thykier wrote:
> Nilesh Patra:
>> 2. Are the following tags still applicable with Build-Driver as debputy?
>>
>
> I am going to group differently.
>
> > - debhelper-compat-virtual-relation
> > - declares-possibly-conflicting-debhelper-compat-versions
> > - no-versioned-debhelper-prerequisite
>
> These /can/ still occur as seen with the `mscgen` case above in theory.
> But there will be cases where `debhelper` is not involved at all and
> then they would not occur.
Got it. However, since it is quite difficult to detect for lintian whether
debhelper
is in use or not, I think these checks for now will need to be skipped when the
Build-Driver is debputy.
> Related to some of them: #1072741
I'll take this up later.
> > - package-uses-debhelper-but-lacks-build-depends
>
> These can still occur as seen with the `mscgen` case above, but I
> recommend not checking for them at this stage as it will be non-trivial
> for `lintian` to do, and I have plans for `debputy` to cover this itself.
Right. The same applies to some of the tags listed above too (i.e. it is
non-trivial
for lintian).
> > - package-uses-dh-runit-but-lacks-breaks-substvar
> > - sphinxdoc-but-no-sphinxdoc-depends
> > - weak-dependency-on-misc-depends
>
> The trigger for these is not exclusively whether you have `Build-Driver:
> debputy` (but it is *a* trigger). Please see #1067653 for the larger
> story. Note, I wrote #1067653 before the `Build-Driver: debputy` case
> existed, which is why it is not mentioned in #1067653 explicitly.
I have a question here:
Since "Build-Driver: debputy" will actually be used in full integration mode,
does
it need a (mandatory) Build-Depends on debputy?
If so, should I add a tag with error severity if this is missing?
Also, I believe I can generally assume if full integration mode is used, these
tags
are not relevant.
>> - python3-depends-but-no-python3-helper
> This one is complicated. Right now `debputy` does not support the python
> tooling, so if you had `${python3:Depends}` with `Build-Driver:
> debputy`, it would be a mistake.
>
> However, `debputy` will complain loudly about this during migration when
> it spots the tooling (it reacts to `dh-sequence-python3` as no go and
> `override` targets as requiring manual intervention), so I do not think
> it will be relevant in practice. Finally, once `debputy` support this
> and a package migrates, then due to #1067653 they can just remove the
> `${pthon3:Depends}` (to hide the warning).
>
> I think you should implement what is easiest for lintian right now on
> this one.
>
> Related, I think this tag will "disappear" over time due to #1067653.
For now, lintian will just skip over this tag in full integration mode.
We can re-visit this later when debputy adds support for python.
>> 3. On what conditions should "package-does-not-use-debhelper" be emitted
>> when Build-Driver is debputy?
>>
>
> I would say, never. The package is using a package helper, which I
> believe is the point of that tag.
>
> The official project decision is still that `dh` is the preferred. So
> the tag about not using `dh` should probably still be emitted (as I
> recall, that is a different tag).
>I disagree with the tag and likely so does any maintainer of the
> packages with `Build-Driver: debputy` since they migrated. However, I do
> not feel that `debputy` is used widely enough that it would make sense
> to challenge the project stance on the prefer package helper(s).
> Therefore, `lintian` should still expect the current project consensus
> on that matter.
Okay, so whenever a package does not use debhelper, which is always assumed for
now whenever things
run in full integration mode, this pedantic tag will be emitted.
In some sense, this will be a false positive if debhelper is used somewhere in
the process, but given
that main build-driver is debputy, it probably makes sense to emit this until
project consensus shifts.
>> 5. If a Build-Driver contains value other than debputy or debian-rules,
>> should an error be emitted?
>>
>
> The `Build-Driver` field is used to load a perl module in
> /usr/share/perl5/Dpkg/BuildDriver/. So the "completionist" answer would
> be if value does not match a known perl module in that directory (with
> the name mangling that `dpkg` does to find the module).
>
> But you could trivially just hard-code these two values for now and move
> on. I doubt we will see a lot of alternatives here. And even if we do,
> they would likely reach out to you. Which brings us to the next question:
I realized that there is no need to do any of this. dpkg refuses to build the
package in the first
place if it can not find the relevant Build-Driver; so lintian does not need
additional checks here.
> I hope this answered your questions, and thanks for working on this. :)
I have one que
Bug#1077938: lintian: Fails to emit `debian-build-system` for packages not using `debian/rules`
On 11/04/26 7:06 pm, Nilesh Patra wrote: > Since "Build-Driver: debputy" will actually be used in full integration mode, > does > it need a (mandatory) Build-Depends on debputy? > > If so, should I add a tag with error severity if this is missing? > > Also, I believe I can generally assume if full integration mode is used, > these tags > are not relevant. > > ... > > I have one question for you to answer above. Looks like this question is also moot, as the package once again, would not even build without this, as I saw on salsa CI - https://salsa.debian.org/nilesh/lintian/-/jobs/9398004/raw > And I have opened a MR implementing Build-Driver changes. May I ask you to > review and let me know > if you see any false positives, or anything else that I should fix? > > That'd be very helpful. MR: > https://salsa.debian.org/lintian/lintian/-/merge_requests/697 Review would be great, though! :) Best, Nilesh
Bug#1077938: lintian: Fails to emit `debian-build-system` for packages not using `debian/rules`
Nilesh Patra:
Hi Niels,
Hi Nilesh,
Thanks for looking into this issue. :)
On `mscgen/0.20-16`, lintian does no emit `debian-build-system` (not
even a `other` value) meaning that `mscgen` will no longer "count" in
the trends.d.n graph over build systems used by packages.
From my PoV, I would hope that lintian would instead use the
`Build-Driver` value as `debian-build-system` when it is different from
`debian-rules` (that is the default value). When it is `debian-rules`
(or the field is omitted), then the existing logic could be used as-is.
I am not very familiar with debputy and the ramifications of the Build-Driver
field and would like to clarify a few things here:
1. I see mscgen has a B-D on debhelper, and debputy at this time can't function
completely independent of dh. So should debian-build-system emit both
debhelper and debputy?
What is happening is that `mscgen` needs `dh_autoreconf` since it uses
GNU autotools. Since `dh_autoreconf` is a `debhelper` tool, you need a
`debhelper-compat` to run it (the command will fail without it). If the
source package had been using `meson` or `cmake`, then there would been
no need for `debhelper` at all.
I would still consider this `debputy` being the `debian-build-system` as
it is the main entry point for the build with `debhelper` being an
implementation detail for the concrete case.
FWIW, when I created `debian-build-system`, I thought of it as "what is
the primary package helper/framework is the package using" to add some
extra context to my view. As in, if I was to read the source of this
package, what helper/framework would I be meeting in its packaging
instructions.
Some added context: The `cdbs` build system was almost exclusively
"cdbs with debhelper" underneath it (`.../debhelper.mk`), but it was
still `cdbs` with no separate `debhelper`. Same story with `dh`. The
`dh` vs. `debhelper` (classic) is the same logical framework but two
vastly different modes of operation. Even so, you either got `dh` or
`debhelper` never both. Finally, the (now) default `dhmk` was a
replacement of `dh` that invoked `debhelper` commands. It was also
"just" `dhmk` (without separate `debhelper` tag).
With all these cases, I feel it would be odd for `Build-Driver:
debputy` to sometimes get a separate `debhelper` variant of this tag on top.
But I suspect given the question you had, it might be time to consider
whether the tag name and description is clear enough on what the purpose
of the tag is.
2. Are the following tags still applicable with Build-Driver as debputy?
I am going to group differently.
> - debhelper-compat-virtual-relation
> - declares-possibly-conflicting-debhelper-compat-versions
> - no-versioned-debhelper-prerequisite
These /can/ still occur as seen with the `mscgen` case above in theory.
But there will be cases where `debhelper` is not involved at all and
then they would not occur.
Related to some of them: #1072741
> - package-uses-debhelper-but-lacks-build-depends
These can still occur as seen with the `mscgen` case above, but I
recommend not checking for them at this stage as it will be non-trivial
for `lintian` to do, and I have plans for `debputy` to cover this itself.
> - debhelper-compat-file-is-missing
No. There is not a requirement for using `debhelper` with `Build-Driver:
debputy` (it depends on which upstream build system is used - autotools
uses part of `debhelper`, most others do not and should not require a
`debhelper` dependency at all).
But related to this, please see #1072741.
> - package-uses-dh-runit-but-lacks-breaks-substvar
> - sphinxdoc-but-no-sphinxdoc-depends
> - weak-dependency-on-misc-depends
The trigger for these is not exclusively whether you have `Build-Driver:
debputy` (but it is *a* trigger). Please see #1067653 for the larger
story. Note, I wrote #1067653 before the `Build-Driver: debputy` case
existed, which is why it is not mentioned in #1067653 explicitly.
- dh-exec-private-helper
- maintainer-script-lacks-debhelper-token
- executable-debhelper-file-without-being-executable
- package-uses-dh-exec-but-lacks-build-depends
- missing-build-dependency-for-dh-addon
No. I do not see how these can occur with `Build-Driver: debputy`, so I
do not expect these to be relevant.
- python3-depends-but-no-python3-helper
This one is complicated. Right now `debputy` does not support the python
tooling, so if you had `${python3:Depends}` with `Build-Driver:
debputy`, it would be a mistake.
However, `debputy` will complain loudly about this during migration when
it spots the tooling (it reacts to `dh-sequence-python3` as no go and
`override` targets as requiring manual intervention), so I do not think
it will be relevant in practice. Finally, once `debputy` support this
and a package migrates, then due to #1067653 they can just remove the
`${pthon3:Depends}` (to hide the warning).
I think yo
Bug#1077938: lintian: Fails to emit `debian-build-system` for packages not using `debian/rules`
Hi Niels, > On `mscgen/0.20-16`, lintian does no emit `debian-build-system` (not > even a `other` value) meaning that `mscgen` will no longer "count" in > the trends.d.n graph over build systems used by packages. > > From my PoV, I would hope that lintian would instead use the > `Build-Driver` value as `debian-build-system` when it is different from > `debian-rules` (that is the default value). When it is `debian-rules` > (or the field is omitted), then the existing logic could be used as-is. I am not very familiar with debputy and the ramifications of the Build-Driver field and would like to clarify a few things here: 1. I see mscgen has a B-D on debhelper, and debputy at this time can't function completely independent of dh. So should debian-build-system emit both debhelper and debputy? 2. Are the following tags still applicable with Build-Driver as debputy? - dh-exec-private-helper - maintainer-script-lacks-debhelper-token - weak-dependency-on-misc-depends - package-uses-dh-runit-but-lacks-breaks-substvar - debhelper-compat-virtual-relation - debhelper-compat-file-is-missing - declares-possibly-conflicting-debhelper-compat-versions - executable-debhelper-file-without-being-executable - package-uses-debhelper-but-lacks-build-depends - package-uses-dh-exec-but-lacks-build-depends - no-versioned-debhelper-prerequisite - missing-build-dependency-for-dh-addon - python3-depends-but-no-python3-helper - sphinxdoc-but-no-sphinxdoc-depends 3. On what conditions should "package-does-not-use-debhelper" be emitted when Build-Driver is debputy? 4. Related to point "2." how would dh-addons be handled? Does debputy use them internally or an explicit rules is required somewhere? 5. If a Build-Driver contains value other than debputy or debian-rules, should an error be emitted? 6. If a Build-Driver contains a different value than debputy or debian-rules, but has B-D on debhelper, should any of the tags specified in 2. be emitted? Please let me know. Best, Nilesh
Bug#1077938: lintian: Fails to emit `debian-build-system` for packages not using `debian/rules`
Package: lintian Severity: normal X-Debbugs-Cc: [email protected],[email protected] Hi (CC: [email protected] since it affects trends.d.n) The `dpkg-dev` version in testing supports the new `Build-Driver` field in source stanza of `debian/control` that determines how `dpkg-buildpackage` will build the package. If omitted, it defaults to `debian-rules` meaning `dpkg-buildpackage` will use the `debian/rules` interface. We are experimenting with this `Build-Driver` interface and the first package (`mscgen/0.20-16`) has been uploaded to unstable where it no longer uses `debian/rules` (it does not even have a `debian/rules`). On `mscgen/0.20-16`, lintian does no emit `debian-build-system` (not even a `other` value) meaning that `mscgen` will no longer "count" in the trends.d.n graph over build systems used by packages. From my PoV, I would hope that lintian would instead use the `Build-Driver` value as `debian-build-system` when it is different from `debian-rules` (that is the default value). When it is `debian-rules` (or the field is omitted), then the existing logic could be used as-is. However, failing that, `lintian` should at least emit a `debian-build-system other` so the package is at least counted in the trends.d.n graphs. Best regards, Niels
