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
> 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
Oh yeah, this way we can solve problem described in #1073 but having some
script which will put license thing into the `$pkgname.license`.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
After lots of refactorings, I’re reduced the complexity of fonts/go (not
published yer) header generation to the trivial
https://pagure.io/fonts-rpm-macros/blob/009ccace3f337f3410cf0b4b789af692fce766d7/f/rpm/lua/srpm/fonts.lua#_135
And setting the rpm variables that uses in a safe way in
So I guess this is waiting for me to put my thoughts here…
# Features (extras)
* In Rust, `Cargo.toml` contains information about all "features" which should
be in their own subpackages, like `%package devel+$FEATURE`.
* In Python, `egg-info` or `dist-info` or similar contain info about
And, you absolutely need the pivot and subvariables set spec-wide, in the
preamble or some early section, because a lot of the domain info will be used
in several spec sections, not just in %files, %build, %whatever.
For example Free Desktop people invented the idiotic appstream descriptor for
Forgot to mention that %subpackages section should store files in the
%{buildroot} too, so that there is possibility to write generators which would
depend on whole state of subpackages (current problem with dependency
generators).
--
You are receiving this because you are subscribed to this
It is user friendly. It is not maintenance friendly because it workarounds rpm
defficiencies (a lot of the complexity is creating lua arrays when rpm does
expose an array element)
> Exactly because of this. I don't want to have overcomplicated macros, I want
> simple configuration which I can
> So I guess this is waiting for me to put my thoughts here…
A lot of those things are already handled Fedora-side in our fonts and go
packaging macros.
1. you define a pivot `%{fooX}` variable, with X a suffixed index à la
%{SOURCEX}. If it is present in the spec file, that means you need to
> A lot of those things are already handled Fedora-side in our fonts and go
> packaging macros.
Sorry, I'm not interested in this black magic which nobody except you
understand. I am interested in user-friendly solution which is supposed to be
implemented in RPM.
> You end up with a huge list
@ignatenkobrain: Unlike the Go stuff, the fonts Lua macros are considerably
simpler to understand, just there's a lot of functions.
But @nim-nim, I agree that we need this functionality natively in RPM. The
contortions that openSUSE goes through to generate flavor subpackages for Ruby
and
> It is user friendly. It is not maintenance friendly because it workarounds
> rpm deficiencies. A lot of the complexity is simulating arrays from
> individual suffixed variables when rpm does expose an array element.
That is exactly why I said having new section like `%subpackages` where
> echo "MIT" > subpkg1.license
> sed -i -e "/^useless-thing.pdf$/
That’s actually much worse than what the go and fonts macro do. It’s only
simple because you’re thinking small with a single conf variable. And did not
code reading back, overriding and fallbacking those variables (common
13 matches
Mail list logo
