On lines 1228 and 1229 in build/files.c, I found this:
if (!isSrc && isDoc(fl->docDirs, flp->cpioPath))
flp->flags |= RPMFILE_DOC;
git blame shows this has been around for at least 8 years, so this is hardly
anything new. I noticed that any files in install to %_defaultdocdir as
This will need Python bindings and test-cases before merging, right now I'm
mostly interested in comments.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
The transaction element change notification callback submitted as #1367 now
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Add support for an optional callback hook for reveiving notifications
about added and deleted transaction elements. This lets API clients
easily track which elements get created and/or replaced by a single
rpmtsAddFoo() call and adjust their own book-keeping accordingly.
Also makes for an easy
To clarify, in the C API the only change is the first callback-argument
changing from a header to rpmte, ie (rpmte, what, amount, total, key,
userdata). Key is redundant and could be dropped, because you can trivially get
it from the rpmte now, but that would make this much more complicated for
As discussed in #1363, this alone does not make for a nice API at all, because
there's no way to track what, if anything, rpmtsAddFoo() actually added. That
will be addressed separately, this is merely about having a means to attach
truly application private data to transaction elements.
--
Split into #1365 and #1366
--
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/1363#issuecomment-695956623___
Rpm-maint mailing
Closed #1363.
--
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/1363#event-3787327370___
Rpm-maint mailing list
The key passed to rpmtsAddInstallEleemnt() and associated with
transaction
elements is sometimes mistaken for user data, but it is not, as rpm relies
on it having a very specific meaning and is passed around with that very
assumption.
API users have all sorts of (legit!) needs, lets add a proper
Add API to get and set callback style, defaulting to the good ole
header first style and add a new style where a transaction element
is passed in place of the header, allowing a much saner interaction.
This is doubly so in Python, where the old style callback is a
braindamaged mess. In the new
Merged #1361 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/1361#event-3787291425___
Rpm-maint mailing list
SOURCEPACKAGE is used for identifying *source packages*, ie it's set to 1 on
src.rpm headers.
If we added SOURCENAME, the next person would want SOURCEVERSION, -RELEASE and
-EPOCH, (because they can differ from the binary package counterparts) and so
on. The idea is that SOURCERPM tells you
So yes, the API for setting the user data is difficult for the time being, that
will be dealt with separately. Perhaps I should split off the user data part to
make this clearer.
The main concern in this PR is the new transaction callback mode and the its
arguments.
--
You are receiving this
See my comments
https://github.com/rpm-software-management/rpm/pull/1360#issuecomment-694728992
and
https://github.com/rpm-software-management/rpm/pull/1360#issuecomment-694875388
- this does not *yet* include a new callback API for notifications about
transaction element changes, which will
@pmatilai Thanks for PR. Passing user data was missing for long time.
I have a note on setting up user data. We have a new API function `void
rpmteSetPriv(rpmte te, void * priv)`. But when an user creates a new
transaction element (using
15 matches
Mail list logo
