Having some of this support built-in RPM (or a set of standard macros) will be
very useful for packages like `grub2`, that not only are split in different
subpackages but also have architecture and firmware interface specific
subpackages.
Fedora's
Anyway, I needed to solve quite a lot of the problems involved in automated
packages to prepare the switch of Fedora Go packages to Go modules.
I will push soonish the result to redhat-rpm-config (not because the Go
automation is finished, I’d say it’s 90% done but in need of lots of testing,
Ah, I forgot that he talked about it too.
--
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/329#issuecomment-635976924___
no Florian gave a talk about it.
https://media.ccc.de/v/2501-re-thinking-spec-files
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
It is the thing that @ignatenkobrain and I were talking about last year, yes.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Isn't this basically the template idea that was presented at the opensuse
conference in 2019?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
cc: @hroncok This is something we should look toward for next-gen Python
packaging stuff.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
cc: @scarabeusiv @darix @coolo This could be relevant for subpackage generation
for Ruby and Python in openSUSE/SLE.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
> @ffesti Thank you for sharing a different analysis and point of view. I’ll
> correct some things here (I don’t fundamentally disagree with what you wrote,
> but you made some shortcuts that would block a real-world design)
>
> > The current font and go macros are a pain to implement but -
@ffesti Thank you for sharing a different analysis and point of view. I’ll
correct some things here (I don’t fundamentally disagree with what you wrote,
but you made some shortcuts that would block a real-world design)
> The current font and go macros are a pain to implement but - obviously -
Looking at this there are a couple of separate issues. I wonder if the reason
this has not been getting anywhere has been that we try to solve all these
different things at once. May be we should split this into separate features
and just start with one - solving only a few - but at least a few
> I guess the easiest way to provide this is a spec file section that is not
> evaluated at parse time but is parsed after the build. We might want to
> disallow some things there but it will basically allow declaring sub
> packages. These could also be created by macros or by scripts
> 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
> 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
@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
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
> 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
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
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…
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
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:
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
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
> 1. you have upstreams from hell like TeXLive that bundle many many unrelated
> parts of the same kind.
So you need some way to tell rpm "autocreate subpackages but split them around
those fileset lines"
Sure. And even in Solus' packaging mechanism, the user can override automatic
pattern
The problem with automated (sub)package generators is that
1. you have upstreams from hell like TeXLive that bundle many many unrelated
parts of the same kind.
So you need some way to tell rpm "autocreate subpackages but split them around
those fileset lines"
2. you still need to declare
In ypkg we have a _priority based_ pattern system, which will also happily
accept absolute paths.
Internally we define subpackages by way of distribution policy, which as well
as automating much of the packaging process, ensures distribution policy is
respect for file and subpackage placement.
FWIW, automating sub packages was considered by Toby in Unity linux back in
2009 (until there were some NZ earthquakes he had to deal with)),
If you do patterns-through-paths, you are going to recreate SELinux policy
maintenance issues: maintaining the patterns globally is rather more abstract
27 matches
Mail list logo
