[Rpm-maint] [rpm-software-management/rpm] rpmbuild sets RPMFILE_DOC on files in %{_datadir}/doc regardless of spec file notation (#1368)
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 defined in the macros end up getting marked in the rpm header with RPMFILE_DOC. This is regardless of how I mark the files in the spec file. If I use any path other than %_defaultdocdir and install files marked as %doc, the spec file rules take effect. But it seems any time you list a file in %files that begins with %_defaultdocdir, it will also be marked as an RPMFILE_DOC in the package. This feels like incorrect behavior to me because the %doc macro is ignored only for these cases. Shouldn't the %doc macro in the spec file control the RPMFILE_DOC bit in the header? -- 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/1368___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Implement a transaction set change notification callback (#1367)
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: https://github.com/rpm-software-management/rpm/pull/1367#issuecomment-696066117___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add support for application private user data in transaction elements (#1366)
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: https://github.com/rpm-software-management/rpm/pull/1366#issuecomment-696065841___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Implement a transaction set change notification callback (#1367)
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 place to set application private data pointers for newly added elements. You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/1367 -- Commit Summary -- * Implement a transaction set change notification callback -- File Changes -- M lib/depends.c (4) M lib/rpmts.c (19) M lib/rpmts.h (33) M lib/rpmts_internal.h (7) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/1367.patch https://github.com/rpm-software-management/rpm/pull/1367.diff -- 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/1367 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Implement alternative transaction callback style (#1365)
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 little to no gain, so leaving it alone. The Python callback is a very different animal. Previously it got (what, amount, total, pkgObj, userdata) as arguments, with pkgObj being either rpmteKey(), RPMTAG_NAME string or None. In this (draft) version, that becomes: (rpmte, what, amount, total, userdata), ie almost the same as C API. The question is whether we should make it the equivalent of the C API, ie with a "key" argument. It's redundant, so I'd kinda prefer to drop it from this new API, but then here's a chance to stop the forever old confusion due to Python and C callback being different... Thoughts? -- 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/1365#issuecomment-695966117___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add support for application private user data in transaction elements (#1366)
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. -- 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/1366#issuecomment-695958854___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] New transaction callback mode based around transaction elements (#1363)
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 list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] New transaction callback mode based around transaction elements (#1363)
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 Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Add support for private user data in transaction elements (#1366)
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 private user data member to transaction elements. The Python bindings to this are kinda dangerous if you liberally mix Python and C as we cant know whether the pointer is an actual Python object or not so we can only assume it is and hope for the best. Nobody in their right mind should be setting user data from one language and accessing it from another, really... You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/1366 -- Commit Summary -- * Add support for private user data in transaction elements -- File Changes -- M lib/rpmte.c (12) M lib/rpmte.h (14) M python/rpmte-py.c (30) M tests/rpmpython.at (14) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/1366.patch https://github.com/rpm-software-management/rpm/pull/1366.diff -- 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/1366 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Implement alternative transaction callback style (#1365)
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 mode the key is not passed as separate argument at all, it can be just as well retrieved via te.Key() for the callbacks needing it. You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/1365 -- Commit Summary -- * Implement alternative transaction callback style with transaction elements -- File Changes -- M lib/rpmts.c (25) M lib/rpmts.h (12) M lib/rpmts_internal.h (1) M python/rpm/transaction.py (4) M python/rpmts-py.c (45) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/1365.patch https://github.com/rpm-software-management/rpm/pull/1365.diff -- 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/1365 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Unbreak build due to defined but not used warning from ensureMacro() (#1361)
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 Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add tag with %{NAME} of SRPM (#1364)
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 where to find the data you're after, so you can then go and query the src.rpm all you want. That said, you're not the first and wont be the the last person asking for this, the more generic request would be for source NEVR in a format that doesn't require ugly unreliable parsing. -- 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/1364#issuecomment-695950934___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] New transaction callback mode based around transaction elements (#1363)
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 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-695936511___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] New transaction callback mode based around transaction elements (#1363)
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 allow you to discover *all* the transaction elements a single rpmtsAddFoo() created. -- 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-695934641___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] New transaction callback mode based around transaction elements (#1363)
@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 `rpmtsAddInstallElement`/`rpmtsAddReinstallElement`/`rpmtsAddEraseElement`) he don't get a pointer to it. Pointer to it (rpmte value) is needed to use the new API function `rpmteSetPriv`. In the `tests/rpmpython.at` all transaction elements are created. Then transaction set is iterated. Transaction elements are modified (user private data added). It is not user friendly API. Ideally we want set it during transaction element creating time. >From your example I assume: - transaction elements are in the transaction set in the order in which the user created them - no transaction elements are automatically added/removed And user can do something like this: ``` ret = rpmtsAddReinstallElement(ts, h, key); int lastAddedTElementIdx = rpmtsNElements(ts) - 1; rpmte lastAddedTElement = rpmtsElement(ts, lastAddedTElementIdx); rpmteSetPriv(lastAddedTElement, user_data); ``` Am I right? -- 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-695916627___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
