The reason for reverting is that there's this unexpected link to %check usage
(and ambiguity) and I think those changes are better handled together. I have
zero more cycles and/or will to spare on this topic right now.
--
You are receiving this because you are subscribed to this thread.
Reply
Ideas for progress:
- [ ] Open a [ticket at Fedora Packaging
Committee](https://pagure.io/packaging-committee/issues) or better send a PR to
[File and Directory
Ownership](https://docs.fedoraproject.org/en-US/packaging-guidelines/#_file_and_directory_ownership)
@pmatilai Could we have an (extra) knob for this behavior and have Fedora
switch it off by default? I think of the main distributions using/contributing
to RPM, only Fedora does not expect to enforce package file list consistency
because it runs no package build verification tools as automatic
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/994#issuecomment-815548834___
Rpm-maint mailing list
Reopened #994.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/994#event-4566954272___
Rpm-maint mailing list
The change got reverted for now, reopening. Sigh.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
> Maybe it's not horrible, only pretty bad :)
It is horrible. See
https://github.com/rpm-software-management/rpm/pull/1442#issuecomment-731554917
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
I think there is no point in arguing. I understand both sides. Let's try
measure the impact of this? Maybe it's not horrible, only pretyy bad :)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
RPM may not immediately break down if one such change is not done, but
maintaining bug compatibility for bug compatibility's sake is a colossal waste
of time, and worse, they sooner or later end up preventing new developments
from taking place. That's why maintaining those undocumented dark
I think your definition of "necessary" differs significantly from mine. RPM
will not break down if this incompatible change is not made (or reverted, now
that you pushed it), so I do not see why it is necessary.
And to give some context: as a maintainer of [TIGCC](http://tigcc.ticalc.org/),
I
If it was unnecessary, I'd agree...
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/994#issuecomment-730362669___
Rpm-maint
> Just like compilers do.
I am also complaining just the same way about compilers doing this. Your
"closing loopholes" is your users' incompatible changes that unnecessarily
break their builds.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly
Yes, I too have seen an endless stream of specfiles deliberately doing all
manner of strange things and abusing loopholes in rpmbuild, and we've been
systematically closing those loopholes as we come across them and time permits,
for (more) consistent and defined behavior. Just like compilers
@kkofler Just because @hroncok is doing that does not mean it was a good idea
to do it that way to begin with. Additionally, that would have been broken
anyway if you tried to `%exclude` a binary file that had associated debug
symbol files, since it would wind up generating a dangling debuginfo
Again: how is this an improvement? I have seen many specfiles deliberately
using `%exclude` in the way that you are now prohibiting. This is an
incompatible change making packaging unnecessarily harder. And Miro @hroncok
even posted a case where the obvious fix (using `rm` instead) won't work
Closed #994 via #1442.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/994#event-4015454938___
Rpm-maint mailing list
16 matches
Mail list logo
