Re: [Rpm-maint] [rpm-software-management/rpm] Handle Python extras trough reverse requirements encoded in provides (#1061)
We know the runtime requirements during the build. What do you mena by this? -- 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/1061#issuecomment-584171335___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Handle Python extras trough reverse requirements encoded in provides (#1061)
You can't properly do it right now. It would need to be expanded on buildtime, but buildtime requirements != runtime requirements. -- 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/1061#issuecomment-584169091___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: please add a way to get the unexpanded content of a rpm variable (#582)
One fairly obvious choice here would be %{noexpand:...} as the direct opposite
of %{expand:...}.
--
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/582#issuecomment-584152668___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] %global expands twice (#1049)
Started adding a %define/%global -style %literal directive for this using the new ME_LITERAL flag, but somehow it feels off the mark. I'm wondering if we should just add options to %define instead to allow finer expansion control (and make %global an alias to that) -- 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/1049#issuecomment-584145244___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Handle Python extras trough reverse requirements encoded in provides (#1061)
So either we have a solution trough subpackages that is somewhat nice, but it requires a feature that is missing in RPM and a feature that is missing in DNF, or we do it trough reverse deps and that can be done right now, but is somewhat ugly? -- 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/1061#issuecomment-584144098___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Handle Python extras trough reverse requirements encoded in provides (#1061)
They would depend on main package tied to NVR, and have broken deps after upgrade. And that should be just auto-removed by DNF (no such feature exists, but it is not very hard to implement in dnf.conf `autoallowremove=*+*`). -- 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/1061#issuecomment-584141344___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Handle Python extras trough reverse requirements encoded in provides (#1061)
I still have no idea about what we would do with the obsoleted subpackages. -- 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/1061#issuecomment-584140712___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Handle Python extras trough reverse requirements encoded in provides (#1061)
@hroncok of course that would be nice. And something what we have discussed with @ffesti. He even asked me to send sumup how we would use that in Rust: http://lists.rpm.org/pipermail/rpm-ecosystem/2020-February/000730.html While there is no commitment or anything like that from anybody, I think there is a clear need for this feature and somebody just has to implement it. I guess Florian has some ideas how to actually do it in the code, but better to ask him. -- 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/1061#issuecomment-584140073___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Handle Python extras trough reverse requirements encoded in provides (#1061)
So only trough an external tool. What we are looking at are possibilities to do this in fully automated fashion from the requirements generators. -- 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/1061#issuecomment-584139136___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Handle Python extras trough reverse requirements encoded in provides (#1061)
> Can you do that automatically? Yes, it is done in rust2rpm. It generates spec file with bunch of subpackages for each feature. And dependency generators support them, based on the name of subpackage, it extracts feature and adjust generation of Provides/Requires. -- 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/1061#issuecomment-584138198___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Handle Python extras trough reverse requirements encoded in provides (#1061)
Can you do that automatically? -- 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/1061#issuecomment-584137625___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Handle Python extras trough reverse requirements encoded in provides (#1061)
@hroncok generate bunch of subpackages for the optional features (extras) and support them. -- 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/1061#issuecomment-584135670___ 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 macro-only dependency generators (#1053)
Okay, together with the new RPMMACRO_LITERAL and a whole pile of other escaping-related changes, a path with percent signs can actually be passed unharmed through this. -- 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/1053#issuecomment-584134028___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] A saner way for marco argument escaping (#1060)
> I tried to add it to the buildroot macro (re-)definition, but with buildroot > it is pretty hopeless. rpm's rpmGenPath always expands all arguments, which > leads to the buildroot getting expanded over and over again. Yup, it's %'s all the way down... :turtle: Perhaps we'll get there yet. -- 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/1060#issuecomment-584132990___ 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 macro-only dependency generators (#1053)
@pmatilai pushed 13 commits.
8b1ea52de31a428952a470225b153393489743fe Double the '%' chars when splitting
macro args
c886b359ba5f05eec6a8da34b55437834b7d80ee Fix pointer dereference before
testing for NULL in rpmtdGetNumber()
94623389ba61a3a93decc726ed63e52cca7b3d39 Fix buffer overflow in %{S:...} and
%{P:...} macro primitives
227cddca88fe99b0e2454a45b941adc3d09bd2ce Fix %{uncompress:...}
double-expanding arguments + other miscellania
b551b256eaf03a1e4bfa7174e08f505dde8a5d2d Refactor %{expand:...} handling to
its own function
47dbb3e070efe8ef5583f22d4903a89bcda90d3c Don't double-expand arguments to
built-in macros (#311)
abcb0af241ea9ad0ef8f5a4467885245c0101d15 Refactor %{verbose:...} handling out
of doFoo()
7d3a87ca1838d9a0983ab8532fc697cbca75a1d5 Remove duplicated code in macro
expansion
07cc75f4d4173e5224faa1cb3715c5c7bc8856a2 Add a ME_LITERAL macro flag that
turns off body expansion
cc66df4fa10470356639c47cec0761baccbc4aee Add rpmPushMacroFlags function to
allow the definition of literal macros
490c70d43cb16a794ac6a73c014ddb119cc9cd12 Use RPMMACRO_LITERAL/ME_LITERAL when
defining some macros
18ddc291c30b2527deb974eb7d9a6e5b7f19d5ec Add APIs for testing whether a macro
is defined and whether its callable
d301eb41d0ac6cada357f281ff465f2f0b25b63a Add support for macro-only dependency
generators
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1053/files/53fa6af7a59e307eee0468ad5a94e45906ea2b2f..d301eb41d0ac6cada357f281ff465f2f0b25b63a
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Handle Python extras trough reverse requirements encoded in provides (#1061)
> we already do this for rust packages You do what exactly? -- 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/1061#issuecomment-584129849___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] A saner way for marco argument escaping (#1060)
(Oh, and I renamed ME_NOEXPAND to ME_LITERAL for consistency) -- 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/1060#issuecomment-584127915___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] A saner way for marco argument escaping (#1060)
Merged #1060 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/1060#event-3022749425___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] A saner way for marco argument escaping (#1060)
Ok, done. I also used RPMMACRO_LITERAL at some other places where it made sense. I tried to add it to the buildroot macro (re-)definition, but with buildroot it is pretty hopeless. rpm's rpmGenPath always expands all arguments, which leads to the buildroot getting expanded over and over again. -- 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/1060#issuecomment-584127264___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] A saner way for marco argument escaping (#1060)
pmatilai approved this pull request. Cool, thanks. -- 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/1060#pullrequestreview-355942245___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Handle Python extras trough reverse requirements encoded in provides (#1061)
> This needs to be in python-rpm-generators, that's why I discuss this here. It > can be done "immediately". @ignatenkobrain when can we expect dynamic > subpackages? Hopefully as soon as @ffesti has time :) --- @hroncok, the whole reason to not reimplement the wheel is that we already do this for rust packages. -- 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/1061#issuecomment-584122460___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] A saner way for marco argument escaping (#1060)
@mlschroe pushed 3 commits. 69f083fe169487a95a0b9a4896dad88dcae4331d Add a ME_LITERAL macro flag that turns off body expansion 2c5a7c08acae96ab07ae7c6bcee39616f69f852f Add rpmPushMacroFlags function to allow the definition of literal macros 9c082dc030142eb068a8320ac91f7f106736dcbb Use RPMMACRO_LITERAL/ME_LITERAL when defining some macros -- You are receiving this because you are subscribed to this thread. View it on GitHub: https://github.com/rpm-software-management/rpm/pull/1060/files/42b61f94e8ae14f484184984246d7ea84ae1bf20..9c082dc030142eb068a8320ac91f7f106736dcbb ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Handle Python extras trough reverse requirements encoded in provides (#1061)
@pmatilai Thanks for confirmation :unicorn: -- 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/1061#issuecomment-584109272___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Handle Python extras trough reverse requirements encoded in provides (#1061)
@hroncok , dynamic sub-packages is nothing but a pink pony in our daydreams ATM, don't hold your breath waiting for that to happen. -- 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/1061#issuecomment-584108154___ 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 macro-only dependency generators (#1053)
Blocked until #1060 is merged and this PR updated to pass the argument as a literal. -- 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/1053#issuecomment-584105708___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Buffer overflow in doFoo() (#1019)
Closed #1019 via 94623389ba61a3a93decc726ed63e52cca7b3d39. -- 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/1019#event-3022555772___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] rpm's doFoo function tends to expand twice (#313)
Closed #313 via 47dbb3e070efe8ef5583f22d4903a89bcda90d3c. -- 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/313#event-3022555800___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Bunch of macro fixes and cleanups (#1062)
Merged #1062 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/1062#event-3022555693___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Bunch of macro fixes and cleanups (#1062)
Thanks for the review :) -- 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/1062#issuecomment-584104633___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Handle Python extras trough reverse requirements encoded in provides (#1061)
Note that the subpackages approach has a problem if an extra goes away and it was installed on user machine. Obviously, if we loose extras that are still dependent on, any approach will generate broken dependencies; but with subpckages, any removed subpackages will need to be obsoleted, and I'm afraid that any rpm level automation cannot possibly have knowledge about "subpackages in the past". -- 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/1061#issuecomment-584102311___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Handle Python extras trough reverse requirements encoded in provides (#1061)
> if later, or just a little sooner: Don't bother. > if a bit sooner: Put it in pyproject macros as an implementation detail, but > document that it shouldn't be done manually. As much as possible, ensure it > can be easily switched to dynamic subpackages. > if much sooner (years): Go for it all the way :) This needs to be in python-rpm-generators, that's why I discuss this here. It can be done "immediately". @ignatenkobrain when can we expect dynamic subpackages? -- 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/1061#issuecomment-584098981___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Handle Python extras trough reverse requirements encoded in provides (#1061)
I won't be able to think through all the edge cases soon to give you "this doesn't work, because..." kind of feedback. But "reverse requirements" do look viable. I guess my question is: when can this be done, relative to proper support for dynamic subpackages? * if later, or just a little sooner: Don't bother. * if a bit sooner: Put it in pyproject macros as an implementation detail, but document that it shouldn't be done manually. As much as possible, ensure it can be easily switched to dynamic subpackages. * if much sooner (years): Go for it all the way :) --- @decathorpe > I am also reluctant to introduce another source of "if" rich dependencies, > which still aren't really correctly handled by some tools, not even some dnf > commands (e.g. repoclosure) That sounds like "if" rich dependencies are unfixably unreliable. Should they be deprecated? @decathorpe > Can we extend pyp2rpm to generate these "extras" subpackages automatically in > the .spec files? rust2rpm does it this way for optional crate features. pyp2rpm is a nice tool for initial packaging, but not useful for ongoing maintenance. It generates a specfile for you, but to update, you either need to put in upstream changes (good luck noticing changes in extras!), or re-generate the spec (throwing away any changes you made). To make ongoing maintenance work, anything in pyp2rpm also needs to be doable manually. Instead of "extend pyp2rpm" you want to "change packaging guidelines"; pyp2rpm should follow those (if/when its dev(s) get to it). @decathorpe > I basically meant providing something that can require something - like a > proper virtual package specifed by Provides that can also specify Requires. > So, like a "virtual subpackage" without it being a "real package". Like you > simulate it with your option 3. Sorry, I don't understand. Do you have a better way of doing what "option 3" does, or are you asking if such a better way exists? -- 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/1061#issuecomment-584096928___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Bunch of macro fixes and cleanups (#1062)
mlschroe approved this pull request. Nice! -- 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/1062#pullrequestreview-355887005___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] A saner way for marco argument escaping (#1060)
This leaves __file_name and __file_lineno expansion inconsistent. Please move that commit last, and update the __file_name/lineno manipulation in build/ to use literals too. Other than that I guess this is good to go. -- 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/1060#issuecomment-584090945___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Bunch of macro fixes and cleanups (#1062)
Fix double-expansion of arguments to built-in macros (except for %{expand:..}
whose sole purpose is to double-expand) refactoring the more special cases out
of doFoo() and fixing misc other related bugs in the process. Details in the
individual commit messages.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/1062
-- Commit Summary --
* Fix buffer overflow in %{S:...} and %{P:...} macro primitives
* Fix %{uncompress:...} double-expanding arguments + other miscellania
* Refactor %{expand:...} handling to its own function
* Dont double-expand arguments to built-in macros (#311)
* Refactor %{verbose:...} handling out of doFoo()
-- File Changes --
M rpmio/macro.c (195)
M tests/rpmmacro.at (20)
-- Patch Links --
https://github.com/rpm-software-management/rpm/pull/1062.patch
https://github.com/rpm-software-management/rpm/pull/1062.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/1062
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] ocaml-find-requires.sh should also consider cmxs files (#913)
In which order is `/usr/lib/rpm/fileattrs/*.attr` evaluated? Is there a safe way to override the content of `%_rpmconfigdir/fileattrs/ocaml.attr` (part of rpm.rpm) with another file from my own `ocaml-rpm-macros.rpm` package? -- 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/913#issuecomment-584057996___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
