Replaced by #914.
--
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-545846866___
Rpm-maint mailing list
Rpm-maint@
Closed #878.
--
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#event-2740154684___
Rpm-maint mailing list
Rpm-maint@lists.rpm.o
> Whether SRPM uses DynamicBuildRequires feature
This is can not be answered, though, by looking at the SRPM. It depends on what
system the srpm is built on. It is similar to conditional BuildRequires, etc.
> Whether SRPM has DynamicBuildRequires inserted into it
You mean whether RPM has some
Oh, we can't design rpm features based on what's available via the flawed
repodata format. Really.
--
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-54050836
Ok, so finally I have some free time.
So the requerements were that you should be able to easily (by having just rpm
metadata, aka primary.xml) do following:
* Whether SRPM uses DynamicBuildRequires feature
* Whether SRPM has DynamicBuildRequires inserted into it
--
You are receiving this beca
(rebased to fix the conflict)
--
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-539978167___
Rpm-maint mailing lis
@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/878/files/f09c493d8cd62634984aae163c6555c2d21c60df..f21466f6babe093382294b0f30be395000b15218
__
So actually marking the generated dependencies as automatic is the right thing
to do regardless of what happens here, and doing so fixes the error reporting
on invalid generated deps. Split that into a separate PR #889
--
You are receiving this because you are subscribed to this thread.
Reply t
> 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,
/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
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__
It was requirement from FESCo to be able to see if package uses/has dynamic
BRs. I'll expand on this later today.
--
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#issuec
No, it was only in src.rpms, but it still prevents installing (ie unpacking)
the src.rpm, which is equally wrong. I assume the idea here was to track
ability to *build* such a package, but we lack such a facility and rpmlib()
dependencies track ability to *install*, which is entirely different.
@pmatilai Wait, I thought that rpmlib dependency was only inserted for srpms.
It was in binary RPMs too?! That stinks...
--
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
Test-suite adjusted as per the change.
--
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-537927429___
Rpm-maint ma
@pmatilai pushed 1 commit.
f21466f6babe093382294b0f30be395000b15218 Don't insert rpmlib() dependencies
for dynamic buildrequires
--
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/5adcbfac95eb8e
rpmlib() dependencies are an installability barrier, and dynamic
buildrequires do not qualify: the package cannot be correctly *built*
with older rpm versions, but they will simply fail to parse the spec
due to unknown tag. However rpmlib(DynamicBuildRequires) as it is
injected by rpm 4.15.0 preven
23 matches
Mail list logo
