Le 2025-03-24 14:09, Ian Jackson a écrit :
Julien Plissonneau Duquène writes ("Re: #1092800: git-buildpackage: gbp
clone: do not defuse gitattributes by default"):
Let's start by making one thing clear: running gbp setup-gittatributes
by default on unsuspecting users is a textbook case of regression.
I find the tone of your communicatiion hostile. Please be nice.
There are many ways of being hostile in a discussion. One of them is to
systematically ignore the arguments and the evidence presented by the
other party. Look at what just happened here: I claim that the issue at
stake is definitely a case of regression, with arguments supporting that
claim, and this bug report links to multiple evidence backing that
claim.
I take extra steps to make sure you cannot ignore that claim: I start
the message with it, conclude with it, and use a direct, straight to the
point, unambiguous formulation that you perceived as "hostile".
So I got your attention, but your only comment about that specific claim
(which is nothing less than the core of the issue) is about the tone of
the communication, and that's it. You didn't even agree or disagree with
that claim, there isn't even a hint that you considered it, you just
ignored it and dismissed it completely. And in your technical
explanation that follows you adress absolutely none of the problems that
I've pointed out in your approach.
I'm sorry, but I do not consider that respectful either, and certainly
not a discussion "conducted in a collaborative way", especially as this
is a recurring pattern in these discussions. It's possible that you do
not even realize that you're doing this; please pay attention.
(I have CC'd the Community Team.
Thank you. This is appropriate here and I will keep the Cc; I was
considering contacting them myself as I believe there is a very
unhealthy dynamic going on here, with a few developers pushing their
views and projects at any cost on critical toolchain components without
due discussion and consideration for the issues that they cause.
I'm not sure where the
right place is for the technical discussion; probably a bug against
src:dgit, not against gbp.
For now I'm asking for a change in gbp, not dgit, so here is definitely
the appropriate place to discuss this. Otherwise there is a thread [1]
waiting for you on debian-devel for a discussion across several tools.
As I have explained, I think it is the only reasonable invariant
(probably, the only *possible* one).
So we disagree. I think your choice of invariant is definitely not a
reasonable one as it breaks compatibility with upstream repositories and
common tools and it is never going to cover all possible use cases
anyway. The steady flow of build issues it causes is the proof that it
doesn't work as a universal or even just as a reliable approach.
I also believe that it should be possible to get dgit to work with the
other (and the only correct, from a git perspective) invariant, and that
achieving that would lead to fewer issues overall than the current
approach playing dirty tricks with attributes. This is indeed going to
require some hard work and would be worth a discussion maybe on a dgit
bug report if you were open to reconsidering this position of yours. So
far I'm convinced that you are not, so I won't bother opening it unless
I can have any hope that an actual discussion may happen, and not just
one-way communication repeating the same things over and over.
In the meantime, I fail to see why breaking gbp and salsa the same way
as dgit is an absolute necessity, so I'm asking their maintainers to
revert this default which has been demonstrated to be a regression.
"Universal" meaning it works with every source package.[1]
It doesn't anyway. For example there are source packages that ship empty
directories and expect them for their build, and AFAICT dgit can't
satisfyingly deal with these.
File-transforming gitattributes disrupt the mapping between git and
source packages because they are not reversible. Some source packages
would come out different when converted to git, and back again.
Once again: could you please provide some actual examples of projects
where this would happen?
This would mean dgit would end up making unwanted changes to packages;
One thing I can tell you as a maintainer is that I would definitely be
upset if the git repositories I work on were to be converted to dgit
repositories. I'm now considering implementing defences in build scripts
to make sure this can't happen without having to read a few things
first.
"lossless" compression), meaning not reversible. Considering, for
example, the "text" attribute, for which gitattributes(5) says:
Line endings are normalized
Normalisation is a nonreversible process.
These transformations are reversible in projects that are correctly
setup upstream. Maybe you have a few actual examples where they are not,
as previously requested?
dgit needs a solution that works for *all* source packages, even ones
where it is forced to *import* a tarball form into git. So a design
that works for only 90% (or even more) is not suitable.
As seen above, dgit already can't work for all packages.
But I will happily reuse the same argument for gbp: a default that
doesn't work for *all* expected use cases is not suitable (excluding
dgit+gitattributes use cases, as dgit in its current form is to be
considered broken by design in these cases). This is why I'm asking to
revert this default.
I don't agree. My view is that *gitattributes* are unsound, and
cannot be made sound.
And my view is that this gitattributes defusing trick is unsound and
cannot be made sound. So I guess we agree to disagree there.
Defusing them is indeed incompatible with a small proportion of
eexisting git bracnhes, but typically those git branches (and/or
whatever orig tarballs we're using) can ba adapted to the new regime
without serious difficulty.
No they can't, without breaking out-of-the-box compatibility with other
git tools and repositories. Once again you are dismissing issues here.
Consequently, I regard this change to git-buildpackage as a necessary
bugfix, to enable more predictable behaviour.
This is not a bugfix as it doesn't fix anything, it just breaks things
further. This is a regression, by the very definition of "regression".
As I understand it, gbp has provided an override mechanism so you can
continue to work with your existing git branch. That seems like a
sensible transitional/compatibility arrangemeent.
Yes now I'm aware of the issue, after having spent too much time on it
already, and occasionally still stumbling on it. Others are going to
keep stumbling on it as well, and lose time for no good reason as I am
pretty certain that the actual and proven drawbacks of having attributes
defusing implemented as a default far outweigh the hypothetical and
unproven benefits.
You sound very angry. I don't understand why you are so angry given
Have you considered that, maybe, attempting to discuss these things with
you is a frustrating experience?
that I believe you can continue to do things as you already have done;
all you need is to explicitly override the gbp default.
Sure, but I also need to tell others to override the unsafe gbp default
for working with some repositories, and I expect that once in a while I
will have to explain things to people that didn't read instructions, or
fix said instructions as new paths to breakage are appearing. This is
not exactly the most pleasant perspective.
But this bug is about the default.
Yes it is. That should not be such a big deal to let this go and revert
this unsafe default, right?
Best regards,
[1]: https://lists.debian.org/debian-devel/2025/02/msg00285.html
--
Julien Plissonneau Duquène
