%config(missingok) is documented, however, %missingok is not. Presumably there
is a lot of overlap, but it is unclear if there are any distinctions in when
and how they should be used.
vattrtest.spec only tests %missingok, can I presume that they are equivalent in
function?
--
Reply to this
The manual doesn't include any details about %caps, the only mention is in the
changelog, a couple of command line flags, and specfiles used for testing
purposes.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2832
You are receiving
`%readme` is documented as being obsolete, perhaps it should be removed with a
shim that behaves as though it was marked as `%doc` instead, with a warning
message to change it?
--
Reply to this email directly or view it on GitHub:
The build fails because of a missing include in cmake:
CMake Error at CMakeLists.txt:353 (check_symbol_exists):
Unknown CMake command check_symbol_exists.
Include the needed file to fix the issue.
You can view, comment on, or merge this pull request online at:
TBD
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/2830
-- Commit Summary --
* Replace MKTREE_NATIVE with MKTREE_MODE in cmake
* Refactor
* Toolbox
-- File Changes --
M tests/CMakeLists.txt (34)
M
Group tag is still used by the Mandrake family (Mageia, OpenMandriva, PLD, ALT,
etc.).
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2374#discussioncomment-8024703
You are receiving this because you are subscribed to this
>group tag made optional
Come to think of it, is this considered legacy nowadays? IIRC the Fedora
packaging guidelines and other distros recommend against it, I believe comps
kind of replaced it?
--
Reply to this email directly or view it on GitHub:
Good point! We shouldn't just blindly copy what the normal triggers do here.
There's enough difference that it makes sense to step back for a moment and
think about what functionality and use cases we really want to cover. Thanks,
I'll take that into account :smile:
--
Reply to this email
The thing to ponder about is whether there are other arguments that should be
passed in addition or in stead of these. The only "vision" or "design" behind
this ticket description is "something close enough to other scriptlets that
someone familiar with should feel at home". Which may leave
Thanks, the part about usefulness is actually on point :smile: That said, I
haven't given it too much thought either, this is just the most obvious
solution that comes to mind. I'll ponder about it a bit more but there's
probably not much to ponder about anyway.
--
Reply to this email
Aggregate is what I thought of when writing the description, I don't see
anything else making much sense. But, it's not like I've given this any deep
meditation. Usefulness is all that matters for the arguments, otherwise we
could just as well not bother :sweat_smile:
--
Reply to this email
> * Non-trans scriptlets have should get a second argument reflecting the
> triggering package count
I wonder if we want the triggering package count (`arg2`) to be an *aggregate*
count of all the triggering packages or just that of the *first* match?
There's a subtle difference in the
12 matches
Mail list logo
