Merged #712 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/712#event-2369355438___
Rpm-maint mailing list
Closed #388 via #712.
--
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/388#event-2369355449___
Rpm-maint mailing list
Merged #711 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/711#event-2369232835___
Rpm-maint mailing list
Some minor tweaks to do still:
- Squash the tests to the commit that adds the feature, that's where they belong
- There's an way too long parseRCPOT() line in doBuildRequires() for loop
still, not sure if it's been mentioned before, if not sorry for missing on
previous rounds
- Clean up the test
I didn't suggest to apply the patches. That's a different part of the spec and
different spec verbs.
*However* to apply the correct patches to the correct source archive, you need
to know the corresponding patch list. So basically as many “list of patches”
as you can have source archives.
A
Ok, --quiet issue is fixed. Thank to Igor for helping with this!
Test are also added - and should now also include the new spec and tar ball...
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Pushed an update to make rpmdbIndexIteratorPkgOffsets() const correct while at
it.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
To rephrase a bit, I can see why you'd sometimes want 2.0.0~alpha to be
considered 2.0.0, but also that in other cases not, and rpm cannot magically
know which one you want for a particular case. It'd be nice if there was a way
to explicitly express both cases.
This sort of reminds me of this
Ok, Rebased and merged.
--
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/710#issuecomment-496093898___
Rpm-maint mailing list
Closed #710.
--
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/710#event-2368433852___
Rpm-maint mailing list
Err, no. If its sorts lower than 2.0.0 then it must match the < 2.0.0
dependency, anything else would be a mess that nobody will understand.
How exactly is this a problem for you?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on
Well, technically it's perfectly okay to have a package that's only installable
after the OS installation, not all packages live in repositories and get
installed as a part of system installation. We also do handle this correctly
for almost a decade - such a package fails cleanly
Again, this is not about patch *application* at all.
Why on earth would you want to interleave source unpack and patch application?
You can always just unpack all sources first and apply patches afterwards. As
people have been doing with rpm for the 20+ years of its existence.
--
You are
13 matches
Mail list logo
