The file reading part refactored to a (more) generic helper in PR #886
--
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/874#issuecomment-538393303___
Support for -f is not limited to %files, so it makes sense to have a common
helper to do it. Inspired by the third such case to be added in #874 .
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/886
-- Commit Summary --
*
Nothing against adding -f support, but this adds third variant of essentially
the same code that is in readFilesManifest() and addFileToTag(), with its own
pecularities (at least missing %__file_name macro handling), when we're trying
instead to eliminate these redundancies across the board.
I'
> These problems have no solution on SRPM level. Unless the spec file is
> preprocessed by rpm, no-one knows whether the package will depend on dynamic
> buildrequires feature or not.
Yes, like I said this is no different from any other data in an src.rpm - it is
only valid for the particular e
BuildRecommends is semantically wrong, if it happens to be needed then it is
needed (not recommended).
These problems have no solution on SRPM level. Unless the spec file is
preprocessed by rpm, no-one knows whether the package will depend on dynamic
buildrequires feature or not.
If anything,
Anything in this direction needs to deal with dynamic buildrequires too, one
way or the other, calling in @ffesti and @ignatenkobrain
--
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-managemen
/me -monologue continues...
The minimal change solution to the contains-issue would probably be moving the
existing rpmlib() dependency to a weak dependency tag. We don't have
BuildRecommends: in specs but nothing stops us from inserting such dependencies
into src.rpm headers, and nothing stops
One solution would be introducing a new rpmbuild() dependency namespace that is
for build what rpmlib() is for install. It just seems as an awfully heavy
solution to the problem at hand.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it
The second commit solves the identifiability of generated dependencies in a way
that's actually in line with other such things in rpm.
Now we just need an acceptable solution to the "contains" half. Any information
in the src.rpm is only valid in the very environment it was created in because
o
@pmatilai pushed 1 commit.
f09c493d8cd62634984aae163c6555c2d21c60df Mark dynamically generated
buildrequires autogenerated
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/878/files/f21466f6babe09338229
(accidentally pushed commit intended for other pr and then undone, too many
damn prs...)
--
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/884#issuecomment-538323351_
@pmatilai pushed 0 commits.
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/884/files/4d35e36261a3e30778c833750b2d72ec862601ef..a9117c142c3b84ddb91db71efc0c065d6e2cbd18
__
Ignoring the error code from rpmfcHelper() means that invalid dependencies
get silently ignores. Intentionally not stopping at the first error though,
as it's often useful to get all errors at once.
Add testcases for legal and illegal output from dependency generator.
Fixes #881
You can view, com
@pmatilai pushed 1 commit.
4d35e36261a3e30778c833750b2d72ec862601ef Percolate errors up from rpmfcHelper()
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/884/files/a9117c142c3b84ddb91db71efc0c065d6e2cb
Misplaced parenthesis introduced in commit 148e82833a.
Fixes #872
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/884
-- Commit Summary --
* Fix suspicious condition in selinux plugin
-- File Changes --
M plugins/seli
These messages have been an endless source of confusion and complaint
throughout their existence, to the point that various programs have added
their own "translation" for these messages. Changing the message is
likely
to break those (regex-based) translations but then hopefully the
translations w
I'm afraid we'll have to do a brown paperbag release for 4.15 that replaces the
rpmlib() tracking with something else, and do so ASAP before this spreads any
further. And break existing users at that :(
--
You are receiving this because you are subscribed to this thread.
Reply to this email dir
Ehm. From commit 58dcfddc376a7c97de1432f0082be0d5f01adbcd:
> Source packages contain
Requires: rpmlib(DynamicBuildRequires) <= 4.15.0-1
if the spec contains a %generate_buildrequires section and
Provide: rpmlib(DynamicBuildRequires) = 4.15.0-1
No package can provide rpmlib() depend
Ack, I can understand the need for that, but rpmlib() dependency is not the
right solution.
--
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/878#issuecomment-538277114__
19 matches
Mail list logo
