Re: [Rpm-maint] [rpm-software-management/rpm] RFE: add an override to allow installing content flagged "untrusted" (Issue #2630)
As for an impact statement on this ticket, currently we are stuck at using Fedora 37 as our mock host, since Fedora 38 introduced this new behaviour and does not work with packages from SUSE (at a minimum). Using Fedora 37 as a mock host of course has an expiry date -- when it becomes EOL and unsupported any more. The hope is by that time, this is resolved and we can once again use the latest Fedora. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2630#issuecomment-1689992277 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Obsoleted-by: would be useful in some cases (#1768)
> I'm not sure what problem this solves. It sounds like the actual problem is > that you want `hwloc1` and `hwloc2` to be parallel installable on RHEL 8.3. No. That is not the problem. The problem is that in order to support both RHEL 8.4 and RHEL 8.3, while building on RHEL 8.4 (because one should not build one's software on unsupported older releases of the distro) I have to supply a backport of a newer version of a library for RHEL 8.3 installations due to that library breaking it's ABI on RHEL 8.4. But the package that that library backport is in needs to be cleanly replaced by the distro's package when that node is upgraded to RHEL 8.4. So to be clear, my package foo-1.0 requires hwloc-2.x on RHEL 8.4. But RHEL 8.3 doesn't supply hwloc-2.x but rather hwloc-1.x (notice the SO major version is not appended to the name like, say, SUSE does). So along with foo-1.0, I need to supply hwloc2-2.x that gets installed with my foo-1.0 when being installed on a RHEL 8.3 system. Since RHEL 8.4 supplies hwloc-2.x, only foo-1.0 gets installed on it. Now when a RHEL 8.3 system that my foo-1.0 and hwloc2-2.x is installed on is upgraded to RHEL 8.4, my supplied hwloc2 should be upgraded to the distro supplied hwloc-2.x. My being able to build hwloc2 with an _Obsoleted-by: hwloc > 1_ would achieve this. > This is pretty much a distro policy issue, and while RPM provides mechanisms > for solving this problem without needing `Obsoleted-by`, it's up to the > distro to use that. And this is the problem. I am not the distro vendor. I am a third-party software supplier. I cannot influence how the distro packages and can only influence how **I** package but am missing the tools (_Obsoleted-by: hwloc > 1_) needed to seemlessly integrate with the distro. I am also not going to get the distro vendor to support that older release by supplying a backport for it, so I have to do that myself. But I need to be able to do it in such a manner that it integrates with the distro seemlessly. IMHO, RPM needs to not only support the distro vendor but needs to provide the tools necessary for third-parties (i.e. non-distros) to integrate into the distro. -- 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/1768#issuecomment-914375153___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Define shell to use with %() (#1334)
> if you write compatibly and avoid using any possible extensions there are You end up having to invoke forty-eleven other tools (awk, sed, grep, tr, etc.) to do what bash can do. :-( -- 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/1334#issuecomment-676379342___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Define shell to use with %() (#1334)
Fair enough on being able to invoke various interpreters. I don't have enough interest to lobby for that. But being able to define the posix shell that `%()` uses would be useful and make for more portable specfiles. -- 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/1334#issuecomment-676293776___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Define shell to use with %() (#1334)
@voxik I can't see why Ruby (or python, or awk, or any other interpreter) would not work. As for _supported_, that's not my call. But as you point out, this does allow the spec writer more flexibility in what interpreter their spec evaluates macros, but does require them to define the shell in their spec to get something other than the default `/bin/sh`. This is not unlike [setting SHELL in Makefiles](https://www.gnu.org/software/make/manual/html_node/Choosing-the-Shell.html). -- 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/1334#issuecomment-675493794___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Define shell to use with $() (#1334)
It would be nice to be able to define which shell should be used with `%()` given that `/bin/sh` is not the same shell on all distros. Additionally having to write `$()` macros to the lowest common denominator is just ugly. It's much nicer to just make _bash_ a `BuildRequires:` and be able to write bashisms in`%$()`. Particularly given that most(?) distros do use bash for `/bin/sh` and only a few outliers 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/issues/1334___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
