> 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 c
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 "extras"
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 t
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:
https://github.com/rpm-software-manag
> 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 g
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 presenc
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
> 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
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 t
@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 Pytho
> 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 anybo
> 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
configu
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 ni
13 matches
Mail list logo
