Re: [Rpm-maint] [rpm-software-management/rpm] Question: the way to check if "load" macro is built-in in a spec file (#1104)
This is intentional change and the explanation is here in the [commit message](https://github.com/rpm-software-management/rpm/commit/9343ecd94cd873e6dc1c06428975163cbb9cf9af). Since you are using new RPM to build SRPM which is targetting older system, now it is probably time to find some workaround. E.g. test the existence of `%load` built-in. -- 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/1104#issuecomment-609760700___ 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: rpm without database (#1151)
that's a good start at least. There's also --importdb. So with slightly more code that could sync back and forth with a directory -- 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/1151#issuecomment-609752886___ 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: rpm without database (#1151)
@lnussel If you want that, just write a post-transaction trigger to run `rpm --exportdb` somewhere... -- 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/1151#issuecomment-609743838___ 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: rpm without database (#1151)
Note that installing the headers on disk as part of package installation does not exclude actually using one of the existing database formats. -- 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/1151#issuecomment-609743345___ 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: rpm without database (#1151)
Closed #1151. -- 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/1151#event-3204921026___ 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: rpm without database (#1151)
Would it be possible to implement a "filesystem" database backend? Most likely. We've even tossed it around a few times between ourselves, but there's just very little benefit and all manner of downsides, such as those @Conan-Kudo already mentioned. I wouldn't call locking, atomic operations and the like "obfuscation". I don't see us working on this, and because of those issues I don't see us wanting to maintain one even if somebody else did the work up front. -- 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/1151#issuecomment-609740176___ 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: rpm without database (#1151)
> I have no insight to the other database formats so can't comment on how that > is handled. For setups that never modify the running system but rather either > prepare images or modify snapshots the transactional capabilities of rpm do > not matter anyways. If anything goes wrong, no new snapshot/image gets > produced. But that's not even close to the common case that RPM is used for. Any feature added to RPM must be considered holistically useful and made relatively safe (within the context of RPM packaging management). Virtually everything is safe in the model of using installroots and snapshots, but most usage of RPM is on live systems, so that makes it difficult to justify this feature. -- 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/1151#issuecomment-609734724___ 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: rpm without database (#1151)
> * People can and will randomly manipulate files to force the package > manager to do weird things (it's even documented in various troubleshooting > guides) Well, obfuscating the database for the purpose of avoiding people to mess with it doesn't sound like an overly good motivation. RPM headers would still be binary and are signed, so you can't arbitrarily edit them like text files anyways. > * It is not possible to atomically update package information, nor > provide any transactional qualities. This means also it's possible to have > races all over the place, depending on filesystem and OS semantics. I have no insight to the other database formats so can't comment on how that is handled. For setups that never modify the running system but rather either prepare images or modify snapshots the transactional capabilities of rpm do not matter anyways. If anything goes wrong, no new snapshot/image gets produced. -- 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/1151#issuecomment-609733671___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Convert few simple generators for a parametric ones + fix for parametric generators (#1163)
Thanks for merging that part. Anyway, those generators are very simple and I think having them as parametric ones make sense. Related to this, I have not seen your opinion on moving these things to a rpm-extras and start actually releasing those things and inform distributions. WDYT? -- 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/1163#issuecomment-609709709___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Convert few simple generators for a parametric ones + fix for parametric generators (#1163)
Oh and FWIW, the double-buildroot bugfix merged separately via #1165. -- 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/1163#issuecomment-609708375___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Question: the way to check if "load" macro is built-in in a spec file (#1104)
Possibly here is a part of the logic causing the error. https://github.com/rpm-software-management/rpm/blob/10127cdb2364de2c1408950a25b730920e665689/rpmio/macro.c#L638-L641 Here is the testing code to test the logic. https://github.com/rpm-software-management/rpm/blob/10127cdb2364de2c1408950a25b730920e665689/tests/rpmmacro.at#L28-L40 The change causing the error comes from the commit: https://github.com/rpm-software-management/rpm/commit/d86c0c28ab74686c59c81a38d04210f70456ce63 for the logic, and the commit: https://github.com/rpm-software-management/rpm/commit/9343ecd94cd873e6dc1c06428975163cbb9cf9af for testing code. -- 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/1104#issuecomment-609706113___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Convert few simple generators for a parametric ones + fix for parametric generators (#1163)
debuginfo deals with any number of files *per package*, whereas there generally is just one metainfo/desktop file in a single package. A single fork+exec in a context of a build is lost in the noise, but when you deals in the dozens it starts to add up. -- 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/1163#issuecomment-609701416___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] rpmfc: Do not prepend buildroot to a path for parametric generator (#1165)
Thanks @ignatenkobrain for spotting and the patch. I must've just looked at runCmd() being passed buildRoot and thinking it's there to be prepended to the path, "obviously", when its actually being passed down a dozen layers or so just to set RPM_BUILD_ROOT environment. Doh. :roll_eyes: I have a hard time understanding how I did not notice the double buildroot there in my original testing though :thinking: -- 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/1165#issuecomment-609700114___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] rpmfc: Do not prepend buildroot to a path for parametric generator (#1165)
Merged #1165 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/1165#event-3204580405___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] %1 in parametric generator contains doubled %{buildroot} (#1162)
Closed #1162 via #1165. -- 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/1162#event-3204580420___ 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: Add possibility to generate Requires(meta) by a dependency generators (#1164)
The generator mechanism needs to learn to deal with multiple files in a go, preserving the per-file nature of the resulting data. We're not making any changes that would make that transition any more difficult that it is, so this is no way 4.16 material. In principle, while some new developments tend to land between alpha and beta releases, an alpha should generally be considered feature complete. The road to stability is bugfixes, not new last-minute features :slightly_smiling_face: -- 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/1164#issuecomment-609696504___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Convert few simple generators for a parametric ones + fix for parametric generators (#1163)
@pmatilai if debuginfo qualifies, why metainfo one would not? They are essentially doing very same simple thing. Another point to WHY to do it is to speed up generators. The desktop one is very simple and can save bunch of fork()s, so why not to replace it? -- 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/1163#issuecomment-609695218___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] rpmfc: Do not prepend buildroot to a path for parametric generator (#1165)
Submitting @ignatenkobrain 's patch as a separate PR because this is a clear and simple bugfix that deserves to be fixed fast and regardless of any other changes. -- 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/1165#issuecomment-609689169___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] rpmfc: Do not prepend buildroot to a path for parametric generator (#1165)
fn already contains full path to a file, so no need to prepend it once
more. This is actually breaking things.
Before:
D: Calling %{__pythonname_provides %{?__pythonname_provides_opts}}() on
/home/brain/rpmbuild/BUILDROOT/hello-1-1.fc33.x86_64//home/brain/rpmbuild/BUILDROOT/hello-1-1.fc33.x86_64/usr/share/applications/org.gnome.Terminal.desktop
After:
D: Calling %{__pythonname_provides %{?__pythonname_provides_opts}}() on
/home/brain/rpmbuild/BUILDROOT/hello-1-1.fc33.x86_64/usr/share/applications/org.gnome.Terminal.desktop
Fixes: https://github.com/rpm-software-management/rpm/issues/1162
Signed-off-by: Igor Raits i.gnatenko.br...@gmail.com
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/1165
-- Commit Summary --
* rpmfc: Do not prepend buildroot to a path for parametric generator
-- File Changes --
M build/rpmfc.c (6)
-- Patch Links --
https://github.com/rpm-software-management/rpm/pull/1165.patch
https://github.com/rpm-software-management/rpm/pull/1165.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/1165
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Convert few simple generators for a parametric ones + fix for parametric generators (#1163)
Mm. We don't want to convert everything to parametric macros just because we *can*, because they're just harder to debug and otherwise work on for the casual observer. Only convert those were it actually makes a difference: those that affect large number of files per package. Of these, debuginfo certainly qualifies but the rest don't. -- 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/1163#issuecomment-609683435___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
