The worst offenders are already gone, closing. If/when there are further
leftovers we can deal with them as they come up.
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
Closed #1211.
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1211#event-4238455699___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
Numbers from Mageia, nothing big, and that's easy to cleanup anyway in a single
commit:
```
%__cp - 106
%__mv - 79
%__cc - 30
%__ln_s - 28
%__sed - 21
%__grep - 10
%_javadocdir - 3
%_javadir - 3
%__lzma - 3
%__cxx - 3
%__id_u - 2
%__ar - 2
%__file - 2
%__as - 2
%__ranlib - 2
%__chgrp - 2
For Mageia we recently discussed either publishing a snapshot or exporting
regularly to git as several people have checkouts that they use for mass
changes but it doesn't exist yet.
`svn co svn://svn.mageia.org/packages/cauldron` is not great because then you
get all releases of the package,
Okay, that's useful. Thanks!
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1211#issuecomment-626642290___
Rpm-maint mailing list
There is even online search included:
https://github.com/bmwiedemann/openSUSE/search?q=__cc
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
@pmatilai I think @pterjan might know for Mageia. You might be stuck just doing
`svn co svn://svn.mageia.org/packages/cauldron` for that. For openSUSE,
@bmwiedemann has a Git mirror of the specs from OBS here:
https://github.com/bmwiedemann/openSUSE
--
You are receiving this because you
@Conan-Kudo , @mlschroe (or anybody in the know) - is there a place where one
could grab the entire collection of Mageia and openSUSE patches similarly to
this Fedora daily snapshot by in Fedora:
http://pkgs.fedoraproject.org/repo/rpm-specs-latest.tar.xz ? It'd be a very
valuable thing to have
Not just small commits but small PRs, fed over time. My capacity for dealing
with people complaining about breakage is well over quota for this year (not
your fault certainly)
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
@pmatilai too late , but I will split PR in to small commits.
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1211#issuecomment-626622183___
Right, that underscore-mismatch makes me wonder if it ever was used (and
whether it works) at all...
If you do PR's, please do so in small pieces at a time, eg only totally
non-controversial removals in a one PR.
--
You are receiving this because you commented.
Reply to this email directly
>
> Note that %__remsh (and through that, %__rsh and %__ssh) are actually used by
> rpm itself (in %___build_cmd) for remote execution of build scripts (a kind
> of cross-build setup).
Ah, that is trivial.
```
801:%___build_cmd %{?_sudo:%{_sudo} }%{?_remsh:%{_remsh}
> Note that %__remsh (and through that, %__rsh and %__ssh) are actually used by
> rpm itself (in %___build_cmd) for remote execution of build scripts (a kind
> of cross-build setup).
hmm, probably I did not notice that.
> The selinux stuff can probably go without further ado, ditto with the
>
Note that %__remsh (and through that, %__rsh and %__ssh) are actually used by
rpm itself (in %___build_cmd) for remote execution of build scripts (a kind of
cross-build setup).
The selinux stuff can probably go without further ado, ditto with the id-stuff,
including chown/chgrp which you can't
Most of __id_u occurrences are from BuildRoot definition. The javadir and
javadocdir are overriden by javapackages, so I'd proposed to keep:
```
%__sed
%__cp
%__mv
%__cc
%__cxx
%__cpp
```
the rest IMO can be dropped without problems.
--
You are receiving this because you commented.
Reply to
@pmatilai in Fedora specs, rough numbers are:
```
%_javadir - 209
%__sed - 168
%_javadocdir - 114
%__cp - 113
%__mv - 76
%__cc - 72
%__ln_s - 24
%__id_u - 20
%__ar - 19
%__cxx - 15
%__grep - 7
%__file - 4
%__as - 3
%__ranlib - 2
%__chgrp - 2
%__restorecon - 1
%__cpp - 1
%_unzipbin - 0
%__ssh - 0
Rather than go mass destruct all at once, it's better to try find things that
are obviously entirely unused by everybody, whether through plain obsolescence
(such as those long obsoleted %_foo*bin compat macros) or the fact that they
cannot be meaningfully used within rpm context. And keep on
> For no real value, yes but still they do are used in the wild and so the
> potential for breakage is quite wide…
Of course, but it is not different from changing other behaviors of RPM. Those
macros are not documented, they are explicitly described as *private to RPM* so
I think making such
Also we probably should rethink `%_(build|host|target)_*` macro. They are not
really used by RPM for anything, rpmPlatform() has its own auto-detection
anyway. I guess they were meant for RPM to support cross-compilation, but this
never happened from what I know.
Probably best would be to get
Basically these macros do not seem to belong to RPM at all:
```diff
--- a/macros.in
+++ b/macros.in
@@ -26,35 +26,18 @@
%__awk @AWK@
%__bzip2 @__BZIP2@
%__cat @__CAT@
-%__chgrp @__CHGRP@
%__chmod @__CHMOD@
-%__chown
I was looking into the macros which RPM ships and there are many things like
aforementioned %__ranlib which is not used in the RPM at all but has been there
forever (at least from 1998).
>From what I understand, %__* is supposed to be something which can affect RPM
>itself, the %_* is for
21 matches
Mail list logo
