On 4/7/21 2:21 PM, Tomas Orsava wrote:
On 4/7/21 12:45 PM, Panu Matilainen wrote:
On 4/7/21 1:12 PM, Tomas Orsava wrote:
On 4/7/21 11:38 AM, Panu Matilainen wrote:
On 4/7/21 12:06 PM, Miro Hrončok wrote:
On 07. 04. 21 10:45, Panu Matilainen wrote:
I'm starting to think the right thing to do is to move %check to
run after %build rather than %install. That would completely
eliminate
arguments over what is proper use and should this or that be done etc.
This is what I don't understand: The current %exclude change is
backwards incompatible and breaks things. How does breaking it even
more help this problem?
Because they kinda go together: the %exclude change revealed that
%check is being used in ways it wasn't really intended to be used -
just like %exclude was - and both "abuses" come with unwanted
side-effects (note quotes, while I know the internal intention, the
intended uses were never clearly documented anywhere)
Further rationale at
https://github.com/rpm-software-management/rpm/pull/1618
I understand wanting a perfect system, but I think it's important to
realize that rpm is a tool for maintainers to simplify their life and
make packaging other software possible.
What you're proposing now is to break thousands of packages with no
advanced warning, no migration path, just because they're using rpm
in a way that wasn't predicted.
Please don't do this.
If you really want to introduce such backwards incompatible changes,
please first work with us maintainers on the migration path and a
reasonable timeline to do so.
Isn't that exactly what we're doing here?
The %check PR may or may not go in, it was linked here so people have
a chance to discuss it. Because there's this just discovered linkage
between %exclude and %check uses, it probably makes sense for them to
go in together. Which could mean doing both, or neither, in 4.17. As
in, reverting the %exclude change in 4.17 is entirely possible if it
makes sense in the grand scheme things.
We cannot possibly know what all the tens of thousands of packages out
there are doing, and people will only ever wake up when the change is
about to hit them. We've done a dozens of similar changes not because
it's fun or because I enjoy getting yelled at for breaking their stuff
but because there's no other way to fix ambiguity than making it
unambiguous.
You're right, knowing the scope of the breakage in advance is just not
possible. We have similar problems with Python, but given the nature of
RPM, you've got it even tougher. I really apologize if it felt like
yelling, that was not my intention.
No worries. Didn't mean to imply *you* were yelling, this has been
entirely civil as far as I'm concerned. I was just referring to years of
battling these issues: for every little loophole in rpm we close in
order to make it saner we get a backslash, and not always so civilized.
It just gets tiresome sometimes. I'm sure you know the feeling. I myself
was kicking and screaming through most of the Python 3 transition, so
been on the other side of it too :)
However, I hope you'll understand why I felt a certain urgency when
writing my response. From my own packaging experience the change would
break a lot of usage, and other people on this thread only reinforced
that this would be a major problem in many areas. And so when I saw that
the follow up to this discussion was a PR that would break even more use
cases, I grew worried.
Yes, message heard. This has been an important discussion to have
because it revealed various things I had no idea about, in particular
the %exclude linkage to %check.
On the other hand, I understand where you're coming from: we have fought
battles with unintended use of our tools too (e.g. sudo pip breaking
dnf). But given the scope of the breakage here, I would advocate for
postponing this change for now. It seems none of us is sure how to
square this circle at the moment.
Nod. I'll need to sleep on this all a bit.
- Panu -
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
