We have way too many checksums in rpm as it is :sweat_smile:
The header is the data by which a package should be identified, because the
whole can differ due to uncompressed vs compressed payload, both of which are
acceptable to rpm as long as the bits are identical.
The generic case here
FYI, I created a new ticket for the generic case: #1756
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
While the overall idea of checking the return of the DB query for the priority
is the right one this patch has several issues. I'll try to come up with
something along the same lines that avoid the issues (returing without freeing
resources, breaking the transaction, using fprint instead of
There's too much history and too many queries out there to change how rpm
behaves here. Also queryformat supports testing for tag existence too and
that'd break if we didn't differentiate between 0 and NULL, effectively.
Note that for the particular case of epoch, you can use `%{epochnum}`
Closed #1681.
--
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/1681#event-5168067801___
Rpm-maint mailing list
A common use-case with macros is wanting to fallback to a default value if the
macro in question doesn't exist, eg "use value of %foo if defined, or 5
otherwise". This seems unnecessarily clumsy in the current macro
implementation: `%{?foo}%{!?foo:5}` and the new expression stuff doesn't seem
Closed #1700.
--
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/1700#event-5167947532___
Rpm-maint mailing list
I can kinda see your point, but this is just too arbitrary a thing to be added
to rpm as such.
There's a more generic use-case behind this: default value for a non-existent
macro. Finding a syntax that would be sufficiently short to be useful might be
hard though.
--
You are receiving this
OK, it looks like this is going to get fixed in the kernel. Closing this here.
In case the kernel fix won't make feel free to re-open the discussion.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Closed #1682.
--
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/1682#event-5167721940___
Rpm-maint mailing list
OK, it looks like this is going to get fixed in the kernel. Closing this here.
In case the kernel fix won't make feel free to re-open the discussion.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Closed #1740.
--
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/1740#event-5167720271___
Rpm-maint mailing list
Closed #1687.
--
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/1687#event-5167695363___
Rpm-maint mailing list
Yes %setup is only executed after all macros have been expanded. So there is
not really a way to do that and relying on $PWD is your best option.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Yeah, documentation also seems to be lacking here. Thanks for the report!
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
The semantics of escaping stuff in %files is not very clear. See also this
thread: http://lists.rpm.org/pipermail/rpm-list/2021-June/002048.html
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Seems to be caused by `__glob_pattern_p()` where a filename containing square
brackets is interpreted as a glob (which then messes up our glob parsing logic
later in the process, resulting in the filename being split into two at the
space char). Will take a closer look.
--
You are receiving
Closed #1713.
--
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/1713#event-5167514653___
Rpm-maint mailing list
This is fixed by #1714. Closing.
--
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/1713#issuecomment-900110489___
Rpm-maint
Looks like a bug someplace.
Wildcards usually get you around obstacles where other escaping methods fail:
`/file?with?spaces?` works, except of course if you have multiple similarly
named files, some using [ ] and others { } etc...
--
You are receiving this because you are subscribed to this
OK, to be more clear: This needs to be fixed by someone with such machine at
hand. It shoudn't be too hard. Patches are welcome.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Implemented in commit 04b0805a756cdd9466fb9dc717846f5bf15518cc, forgot to close.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Closed #1594.
--
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/1594#event-5167379936___
Rpm-maint mailing list
23 matches
Mail list logo
