[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Invalid check in debian/patches

Hi Jonas,

On Sat, 2025-02-01 at 17:05 +0100, Jonas Smedegaard wrote:
Quoting Abou Al Montacir (2025-02-01 16:13:44)


On Sat, 2025-02-01 at 14:37 +0100, Jonas Smedegaard wrote:
Quoting Simon McVittie (2025-02-01 14:21:38)
On Sat, 01 Feb 2025 at 13:13:32 +0100, Abou Al Montacir wrote:
Bug-

I believe the intended DEP-3 syntax for this is:

Bug: https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/41378

so using that instead of Bug-Upstream might help?

My understanding is that the Bug-<vendor> convention is intended
for other downstreams, which might be Debian, a Debian derivative like
Ubuntu, or sometimes an unrelated downstream like Fedora that has provided
useful/relevant information in their record of the equivalent bug.

Agreed that *ideally* an URI for the forwarded bug is provided. But does
the omission *invalidate* the data points of "yes, it has been forwarded
somewhere not mentioned, and has also been forwarded to some downstream
confusingly labelled "Upstream"?
With regards to other possible values (No, NotNeeded), I find it a bit hacky to
use this field to provide an upstream bug URL.
I would completely remove this practice and keep this field human readable and
understandable to be a simple tri-state field (Yes, No, Not-Needed).

If you are proposing a change to the definition of DEP-3, then do you
really think that the benefit of such change outweight the burden of
updating current machinery and declarations?  Because I fail to see it.
I would love to, but as Jeremy spotted out, I'm minority (600 vs 4000) so no.

If not a proposal for change, then what is your point of mentioning it?
That tools do not enforce practice by stating that other practices are errors (which may explain the above mentioned majority)

Tools are here to enforce rules, not to enforce a particular way to comply to them.
I hope this is clear enough.

I suggest to go ahead and file a bug against the service, suggesting to

Sure I'll do that.
clarify (e.g. using a hover string) what causes an invalidation, and
also to choose a different keyword (e.g. "ambiguous" or "weak") when
strictly speaking it is not invalid per the spec but just somehow not
ideal.
* Bug-<Vendor> or Bug (optional)It contains one URL pointing to the related
bug
(possibly fixed by the patch). The Bug field is reserved for the bug URL in
the upstream bug tracker. Those fields can be used multiple times if several
bugs are concerned.The vendor name is explicitely encoded in the field name
so that vendors can share patches among them without having to update the
meta-information in most cases. The upstream bug URL is special cased because
it's the central point of cooperation and it must be easily distinguishable
among all the bug URLs.
My understanding is that this applies to two kind of bug trackers:
1. Upstream using Bug
2. Downstream using Bug-<vendor>

In my case I used Bug-Upstream because I found it on an other patch, but this
point is not very clear in the spec and I would suggest we rewrite it to make is
more explicit.

I agree that it might make sense to refine the non-formal parts of DEP-3
to avoid misunderstanding.

I made same mistake when I began using DEP-3. :-)
If you made a mistake, and I made it, and many made the same, then the spec is not clear enough.

But also, in this particular case, it's not the issue of the spec but of a particular tool trying to enforce the rule.

I'll file a bug to fix it.
-- 
Cheers,
Abou Al Montacir

Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: