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
It's not legit in *rpm* filenames though. See
https://github.com/rpm-software-management/rpm/blob/c1ca2e35025698328edcefa8dedee866d2ea0596/build/files.c#L1329
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
> 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
@hroncok , https://copr.fedorainfracloud.org/coprs/pmatilai/rpm-snapshot/
Rawhide builds are broken at the moment (massive fakechroot breakage, not rpm
itself) but the f33 build ought to work on rawhide too.
--
You are receiving this because you are subscribed to this thread.
Reply to this
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
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:
@Conan-Kudo approved this pull request.
--
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/pull/1317#pullrequestreview-534495168___
@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
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
Previously we only checked for unpackaged files and symlinks, completely
ignoring eg extra directories that might be there. Just check for everything
instead. Related to #994.
Directories are a little tricky as some of them are almost always unowned
so we need to allow all path components leading
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
@Conan-Kudo approved this pull request.
LGTM.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@pmatilai This means that installed empty directories will get caught now too,
right?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
The backends are pretty different, so I don't think it's reasonable to demand
that they all behave the same.
For ndb, you should open the Packages.db read-only but Index.db read-write.
With that you get exactly what this pull request is about, i.e. disabling the
implicit database creation.
--
There will be inevitable differences in details, but we can't have each backend
defining their own semantics for general behavior that will affect user visible
return codes etc. But that bigger picture is beyond the scope here, sure.
I'll update...
--
You are receiving this because you are
Need more coffee...
What I meant in the earlier comment though is that the index creation is such
fundamental behavior that it should behave the same across backends, otherwise
adding new indexes gets just too wacky to live with.
Luckily that's not something that happens often so it's not of
@pmatilai pushed 2 commits.
6ec7f0f45b866bf52ca18501ba360608260e90b9 Stop on first failure when trying to
open a database (RhBug:1898301)
af28fab47e619e4be274d135e4b8e2dbddb513ac Disable implicit database creation on
read-only handle
--
You are receiving this because you are subscribed to
Okay, now the ndb change is in line with the others. I originally did this
weeks/months ago with a commit message reminding me to actually test it, and
clearly the ndb part was not...
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it
Okay, no further comments so with no further ado...
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
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
Merged #1442 into master.
--
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/pull/1442#event-4015454920___
Rpm-maint mailing list
Is there a nighly copr with RPM, so I can measure the impact of this change in
Fedora? I am worried that it will be enormous.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
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
23 matches
Mail list logo
