Closed #1239.
--
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/1239#event-4266561742___
Rpm-maint mailing list
Been thinking about this on and off, and it still rubs me the wrong way. The
spec is a convoluted mess as it is, and even the experienced packagers and
macro developers have difficulties understanding and remembering the different
time and space contexts of macros and build scriptlets which sit
My understanding of the feature is that it will eventually require some
mecanism to reconciliate the subpackage metadata (that the feature directly
targets in the new section) and srpm metadata.
Because without such a mechanism, you’ll be asking packagers to be extra
careful to never put
Is this contribution ever meant to modify the built source RPM content?
I.e. can `%postbuild` be (mis-)used so that `rpmbuild -ba` and `rpmbuild -br`
both generate a different variant of source RPM?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly
That being said, the PR is a nice step in the right direction. It’s just that
its design has limits, and will probably not scale once you start mixing spec
generators with different ideas of where the dynamism should start or end. With
a single section at a single point of the spec generators
> %postbuild is misleading and dangerous. You need a dynamic starting point for
> every section that succeeds %post,
More generally, the problem you are attempting to solve, is not the lack or not
of a new rpm section, and the shredding or not of the existing spec file. Those
are all fuzzy
So here is some quick and hasty feedback (I was going to write a lot more, but
the laptop battery disagreed).
You need to make it possible to generate what exists in the preamble today,
because otherwise the common case where a SRPM generates a single subpackage,
and you want the SRPM metadata
If the intent is to primarily use this to generate subpackages, we should just
call this `%generate_package_definitions` or similar. Do we intend to make this
usable for generating *any and all* spec constructs that would be useful after
running `%prep`, `%generate_buildrequires`, `%build`, and
```
RPM build errors:
line 223: %package -n rust-libc-devel: package rust-libc-devel already
exists
fish: Job 2, “~/Projects/upstream/rpm/rpmbuil…” terminated by signal SIGSEGV
(Address boundary error)
```
Segfault if the package redefinition happens is not expected.
---
```
error: line
@ffesti pushed 1 commit.
9b1a24a921f281747eb475276a3693471ee2b0b1 Add suppport for %postbuild spec
section
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
> I am not 100% sure why this rubs me the wrong way. It just doesn't feel
> right. A few thoughts and observations:
I had a largely similar feeling about this PR so I fair enough :grinning:
The answer is probably somewhere in the middle.
> It is hard to generate spec file fragments from within
> I'd rather see this pushed to an external file entirely. That would
>
> * drive the intended usage home with a sledgehammer
>
> * make it easier to generate spec fragments from %build
>
> * simplify the parsing as you don't need to try not to parse a thing when
> you're parsing
@pmatilai commented on this pull request.
> +while (1) {
+ if ((rc = _readLine(spec, 0, 1)) > 0) {
+ res = PART_NONE;
+ break;
+ } else if (rc < 0) {
+ res = PART_ERROR;
+ break;
+ }
+ if (!strncmp(spec->line, "%%end", 5)) {
+
@ffesti commented on this pull request.
> @@ -451,6 +453,7 @@ const char * rpmSpecGetSection(rpmSpec spec, int section)
case RPMBUILD_BUILD:return getStringBuf(spec->build);
case RPMBUILD_INSTALL: return getStringBuf(spec->install);
case RPMBUILD_CHECK:return
I like "generate spec" better than "post build", the latter only describes
*when* it runs, the former actually gives some idea *what* it does.
I'd rather see this pushed to an external file entirely. That would
- drive the intended usage home with a sledgehammer
- make it easier to generate spec
@ignatenkobrain commented on this pull request.
> @@ -451,6 +453,7 @@ const char * rpmSpecGetSection(rpmSpec spec, int section)
case RPMBUILD_BUILD:return getStringBuf(spec->build);
case RPMBUILD_INSTALL: return getStringBuf(spec->install);
case RPMBUILD_CHECK:
@ignatenkobrain commented on this pull request.
> +while (1) {
+ if ((rc = _readLine(spec, 0, 1)) > 0) {
+ res = PART_NONE;
+ break;
+ } else if (rc < 0) {
+ res = PART_ERROR;
+ break;
+ }
+ if (!strncmp(spec->line, "%%end",
Some bikeshedding here: I'd call it `%generate_spec` because that's what it
essentially is for.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
This is a POC for the new dynamic sub package feature. It add a %postbuild
(better names welcome) section that is not expanded during regular Spec
parsing. It is fed to the spec parser after the build scripts have run. This
allows to create sub packages based on the content of the buildroot.
19 matches
Mail list logo
