Re: [Rpm-maint] [rpm-software-management/rpm] RFE: make possible to pass multiple dirs to `_*dir` macro (#352)
(aside) There are ways to configure rpmbuild to do everything in the current directory. I have published my macros configure file multiple times in the past 15 years. Adding multiple directories and a search path to existing macros like _sourcedir adds complexity for not much gain, and is quite at odds with rpm' goal of "reproducible builds" when identically named but differing files are found in multiple locations. There are also issues unpacking *.src.rpm files: which directory to use? -- 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/352#issuecomment-346920508___ 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: make possible to pass multiple dirs to `_*dir` macro (#352)
(aside) There are ways to configure rpmbuild to do everything in the current directory. I have published my macros configure file multiple times in the past 15 years. Adding multiple directories and a search path to existing macros like _sourcedir adds complexity for not much gain, and is quite at odds with rpm' goal of "reproducible builds" when identically named but differing files are found in multiple locations. There are also issues unpacking *.src.rpm files: which directory to use? -- 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/352#issuecomment-346920510___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Axe yet more unimplemented/unused/redundant cruft from query/verify flags (393879d)
QUERY and VERIFY bits were consolidated int a single enum to *permit* patches to be applied from header content at some point, not otherwise. By all means, one can certainly chose to have separate QUERY and VEIFY logic bits. An equivalent amount (imho) of work on the implementation woul permit applying patches to (usually) configure files from header metadata, which is surely a stronger and more reproducible mechanism than relying on seeds/peel invocations from, say, %post script lets. -- 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/commit/393879d9c58905027741baf68795523bbdd4a32e#commitcomment-25835832___ 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: Finer-grained symbol dependencies (#362)
@miscroe: describing set versions as a "probabilistic method" with it a "small chance" of failure does not jibe with my understanding of the implementation. Please supply reasoning and a reproducer. AFAIK set versions is a clever (and faithful, no probabilistic operations) encoding of a set of symbol strings, whose only failure mode is through misuse, not intrinsic to the set versions implementation. -- 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/362#issuecomment-346913249___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Fix error message for rpmlock (#355), by removing dead code (#358)
I should point out that this is not "dead code" since the existence of a fcntl(2) read lock will prevent a write lock even if rpm itself does not expose the API to test read locks. That being said: your change is entirely sane, the fcntl(2) locking in RPM is badly flawed, made worse by permission checking on 0755 root:root permissions on /var/lib/rpm files. Until the permission problems are reasonably dealt with, your patch is as good as anything else. -- 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/358#issuecomment-346913026___ 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: Configurable macro file search path(s) (#363)
Um, this simply isn't true. RPM has always searched multiple directories for macro definition files. See also the --macros CLI option (which takes a colon separated set of paths to load) to override the default value for macro search paths. -- 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/363#issuecomment-346912506___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] RFE: Configurable macro file search path(s) (#363)
Currently, RPM looks for macro definitions in only one directory, which is hard-coded and cannot be changed. This pose significant complication for packaging of RPM Software Collections which need to provide their own version of macro files – basically, the SCL installs all its files into `/opt//` prefix **except** the macro files, which it has to install system-wide. The process also usually requires heavy modification of said macro files in order for them to not conflict with the "native package" macro files. (As a side note, this modification could benefit from [some kind of name spacing](https://github.com/rpm-software-management/rpm/issues/246).) Would it be possible to consider adding a configurable/extandable macro search paths? -- 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/363___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
