Hi,
Thanks for the follow-up!
On 10/5/26 6:16 AM, Nilesh Patra wrote:
Control: severity -1 normal
On 05/10/26 2:38 am, Thomas Goirand wrote:
Package: lintian
Version: 2.122.0
Severity: important
Hi,
Some of my packages are using debian/po.in, and merge stuff into a debian/po
folder at build time. You can see this in Octavia for example. IMO, this is a
very legitimate use of templates, all located in a single place, used by many
packages.
And then, Lintian doesn't see this, only expect debian/po, and gives me a
bad RED ERROR I'M-SO-BAD thingy.
Please fix this. :)
I see that you do a `cp -auxf debian/po.in debian/po` here[1]. I then don't
quite understand
the rationale behind having a `.in` - what purpose does it serve?
I'm merging templates from openstack-pkg-tools that is used in many
OpenStack services. It's just more convenient this way, to write the
clean target (ie: rm -rf debian/po). The machinery would be a way more
complicated if I had to force myself to use debian/po in the source tree.
This is, IMO, a common case that should be addressed. If you have
suggestions to do it in another way, let me know.
Given that lintian is a static analysis tool, it becomes a bit hard to detect
cases like these
where people use non-standard paths. I could check for `d/po.in` directory and
things inside
the same for po-debconf related checks. But then, someone else may end up using
`d/po.templates`
or `d/templates` or something else.
Quite not: the .in is a very common practice. If someone shows up with a
different name, you may suggest to use .in instead. If you were to ask
me to switch to another directory name, to avoid the Lintian warninig, I
would do it.
Do you happen to have an authoritative list of directories that are common?
The manpage[2] explicitly only lists `d/po` for now.
Right, I don't think there's any authoritative list.
Also, no, this should have NEVER been a bad RED error. The package still would
continue to work if not using po-debconf.
Errors are for cases where it is a policy violation and/or actual packaging
error [2]. It does not
mean that the package will cease to function.
IMO, errors is what makes a package having RC issues. But let's not
discuss this, I don't mind much as long as this false positive is fixed.
Because of hard error from Lintian, I'm setting Severity: important for this
false-positive.
As per [3] it does not warrant an important severity; lowering to normal.
No worries, your call... :)
Cheers,
Thomas Goirand (zigo)
