Merged #1485 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1485#event-7774057590
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
@pmatilai approved this pull request.
Okay the spec parse stuff looks a whole lot nicer now - it actually looks like
an improvement.
I intended to do some more practical testing with this, but enough is enough
:sweat_smile:
--
Reply to this email directly or view it on GitHub:
Rebased on top of #2270 and squashed latest fixes.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1485#issuecomment-1308683146
You are receiving this because you are subscribed to this thread.
Message ID:
@ffesti pushed 3 commits.
a1056d0b1487ee921db9de8d53bf693976e1f0b5 Split actual parsing of spec into its
own function
a2592627c300ddbe9af1632d0681391567213791 Allow starting new spec parts with
PART_EMPTY
26de93c844ee13d456542e867cf35a60e574c90b Add Dynamic Spec generation
--
View it on
OK, seems like all the comments are now addressed.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1485#issuecomment-1308622418
You are receiving this because you are subscribed to this thread.
Message ID:
> Added alternative error handling. Turns out to be less of a change than I
> expected. So it's probably just the way to go.
Yup, looks good.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1485#issuecomment-1308613037
You are receiving
@ffesti pushed 1 commit.
5b4d7065b2f720dd098db92234f496ae59a03882 Dynamic Specs: Add order of specparts
reading
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1485/files/a2ec843b8dbc11ece43f057092b0f768931c933c..5b4d7065b2f720dd098db92234f496ae59a03882
You are
@pmatilai commented on this pull request.
> @@ -1129,3 +1155,29 @@ rpmSpec rpmSpecParse(const char *specFile,
> rpmSpecFlags flags,
{
return parseSpec(specFile, flags, buildRoot, 0);
}
+
+rpmRC parseGeneratedSpecs(rpmSpec spec)
+{
+ARGV_t argv = NULL;
+int argc = 0;
+int i;
@pmatilai commented on this pull request.
> + if (checkForEncoding(pkg->header, 0) != RPMRC_OK) {
+ badenc = 1;
+ }
+ }
+ if (badenc)
+ goto errxit;
+}
+
+closeSpec(spec);
+
+exit:
+return spec;
+
+errxit:
+if (!secondary)
+
Added alternative error handling. Turns out to be less of a change than I
expected. So it's probably just the way to go.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1485#issuecomment-1307049064
You are receiving this because you are
@ffesti pushed 1 commit.
a2ec843b8dbc11ece43f057092b0f768931c933c Move rpmSpecFree out of
parseSpecSection
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1485/files/a07501c24c391ed091f72c2933f259bb617c6185..a2ec843b8dbc11ece43f057092b0f768931c933c
You are receiving
@ffesti commented on this pull request.
> + if (checkForEncoding(pkg->header, 0) != RPMRC_OK) {
+ badenc = 1;
+ }
+ }
+ if (badenc)
+ goto errxit;
+}
+
+closeSpec(spec);
+
+exit:
+return spec;
+
+errxit:
+if (!secondary)
+
@ffesti commented on this pull request.
> + if (checkForEncoding(pkg->header, 0) != RPMRC_OK) {
+ badenc = 1;
+ }
+ }
+ if (badenc)
+ goto errxit;
+}
+
+closeSpec(spec);
+
+exit:
+return spec;
+
+errxit:
+if (!secondary)
+
- Removed u2p macro
- Added _prefix to test case
- Removed unnneccessary rpmSpecFree call
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1485#issuecomment-1306984561
You are receiving this because you are subscribed to this thread.
@ffesti commented on this pull request.
> +
+runroot rpmbuild -ba /data/SPECS/dynamic.spec
+],
+[0],
+[ignore],
+[ignore])
+
+AT_CHECK([
+
+runroot rpm -qp --qf "%{Summary}\n"
/build/RPMS/noarch/dynamic-docs-1.0-1.noarch.rpm
+runroot rpm -ql /build/RPMS/noarch/dynamic-docs-1.0-1.noarch.rpm
+],
@ffesti commented on this pull request.
> @@ -715,7 +715,8 @@ package or when debugging this package.\
RPM_ARCH=\"%{_arch}\"\
RPM_OS=\"%{_os}\"\
RPM_BUILD_NCPUS=\"%{_smp_build_ncpus}\"\
- export RPM_SOURCE_DIR RPM_BUILD_DIR RPM_OPT_FLAGS RPM_ARCH RPM_OS
RPM_BUILD_NCPUS\
+
@ffesti pushed 3 commits.
825d644e5654c1898849c54eb2b7327a9044f7da Split actual parsing of spec into its
own function
a3f967656ccdec466653a12301c7449f9f746975 Allow starting new spec parts with
PART_EMPTY
a07501c24c391ed091f72c2933f259bb617c6185 Add Dynamic Spec generation
--
View it on
@pmatilai commented on this pull request.
> +
+runroot rpmbuild -ba /data/SPECS/dynamic.spec
+],
+[0],
+[ignore],
+[ignore])
+
+AT_CHECK([
+
+runroot rpm -qp --qf "%{Summary}\n"
/build/RPMS/noarch/dynamic-docs-1.0-1.noarch.rpm
+runroot rpm -ql /build/RPMS/noarch/dynamic-docs-1.0-1.noarch.rpm
@pmatilai commented on this pull request.
> @@ -715,7 +715,8 @@ package or when debugging this package.\
RPM_ARCH=\"%{_arch}\"\
RPM_OS=\"%{_os}\"\
RPM_BUILD_NCPUS=\"%{_smp_build_ncpus}\"\
- export RPM_SOURCE_DIR RPM_BUILD_DIR RPM_OPT_FLAGS RPM_ARCH RPM_OS
RPM_BUILD_NCPUS\
+
@pmatilai commented on this pull request.
> + if (checkForEncoding(pkg->header, 0) != RPMRC_OK) {
+ badenc = 1;
+ }
+ }
+ if (badenc)
+ goto errxit;
+}
+
+closeSpec(spec);
+
+exit:
+return spec;
+
+errxit:
+if (!secondary)
+
@pmatilai commented on this pull request.
> @@ -273,6 +273,15 @@ static int doSetupMacro(rpmSpec spec, const char *line)
free(buf);
}
+/* mkdir for dynamic specparts */
+buf = rpmExpand("%{__mkdir} SPECPARTS", NULL);
+appendBuf(spec, buf, 1);
+free(buf);
+
+
OK, addressed all the comments above except the issue with the signature of
`parseSpecSection()` where I not quite see what a better solution would be.
Fixed for now:
- Reworded documentation
- Merged spec files for test cases
- Failing test case checks rpmbuild output
- removed spurious u2p
@ffesti commented on this pull request.
> + if (checkForEncoding(pkg->header, 0) != RPMRC_OK) {
+ badenc = 1;
+ }
+ }
+ if (badenc)
+ goto errxit;
+}
+
+closeSpec(spec);
+
+exit:
+return spec;
+
+errxit:
+if (!secondary)
+
@ffesti commented on this pull request.
> @@ -273,6 +273,15 @@ static int doSetupMacro(rpmSpec spec, const char *line)
free(buf);
}
+/* mkdir for dynamic specparts */
+buf = rpmExpand("%{__mkdir} SPECPARTS", NULL);
+appendBuf(spec, buf, 1);
+free(buf);
+
+buf
@ffesti commented on this pull request.
> +layout: default
+title: rpm.org - Package Build Process
+---
+# Dynamic Spec Generation
+
+Since rpm 4.19 RPM supports parsing dynamically generated specs. This
+allows the build scripts (**%build** or **%install**) to create parts
+of the spec file.
@ffesti commented on this pull request.
> +%description
+Simple rpm demonstration.
+
+%prep
+%setup -q -T -c
+
+%build
+echo "Q: Why?\nA: Because we can!" > FAQ
+
+%install
+mkdir -p $RPM_BUILD_ROOT/usr/local/bin
+echo " " > $RPM_BUILD_ROOT/usr/local/bin/hello
+
+
+echo "%package docs" >>
@ffesti commented on this pull request.
> @@ -273,6 +273,15 @@ static int doSetupMacro(rpmSpec spec, const char *line)
free(buf);
}
+/* mkdir for dynamic specparts */
+buf = rpmExpand("%{__mkdir} SPECPARTS", NULL);
+appendBuf(spec, buf, 1);
+free(buf);
+
+buf
@ffesti commented on this pull request.
> +
+%prep
+%setup -q -T -c
+
+%build
+echo "Q: Why?\nA: Because we can!" > FAQ
+
+%install
+mkdir -p $RPM_BUILD_ROOT/usr/local/bin
+echo " " > $RPM_BUILD_ROOT/usr/local/bin/hello
+
+
+echo "%package docs" >> %{specpartsdir}/docs.specpart
+echo "Summary:
@ffesti commented on this pull request.
> @@ -2272,3 +2272,44 @@ runroot rpmbuild \
],
[ignore])
AT_CLEANUP
+
+# --
+# Check if dynamic spec generation works
+AT_SETUP([rpmbuild with dynamic spec generation])
+AT_KEYWORDS([build])
+RPMDB_INIT
+AT_CHECK([
+
@ffesti pushed 1 commit.
387da564de03e2c12200d09abf746690b103af86 Add Dynamic Spec generation
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1485/files/ab78270fca71149a42fdead2b8dd14a0f2d0898c..387da564de03e2c12200d09abf746690b103af86
You are receiving this because
@pmatilai commented on this pull request.
> + if (checkForEncoding(pkg->header, 0) != RPMRC_OK) {
+ badenc = 1;
+ }
+ }
+ if (badenc)
+ goto errxit;
+}
+
+closeSpec(spec);
+
+exit:
+return spec;
+
+errxit:
+if (!secondary)
+
@dmnks commented on this pull request.
> +%description
+Simple rpm demonstration.
+
+%prep
+%setup -q -T -c
+
+%build
+echo "Q: Why?\nA: Because we can!" > FAQ
+
+%install
+mkdir -p $RPM_BUILD_ROOT/usr/local/bin
+echo " " > $RPM_BUILD_ROOT/usr/local/bin/hello
+
+
+echo "%package docs" >>
@pmatilai commented on this pull request.
> + if (checkForEncoding(pkg->header, 0) != RPMRC_OK) {
+ badenc = 1;
+ }
+ }
+ if (badenc)
+ goto errxit;
+}
+
+closeSpec(spec);
+
+exit:
+return spec;
+
+errxit:
+if (!secondary)
+
@pmatilai commented on this pull request.
> @@ -2272,3 +2272,44 @@ runroot rpmbuild \
],
[ignore])
AT_CLEANUP
+
+# --
+# Check if dynamic spec generation works
+AT_SETUP([rpmbuild with dynamic spec generation])
+AT_KEYWORDS([build])
+RPMDB_INIT
+AT_CHECK([
+
@pmatilai commented on this pull request.
> +%description
+Simple rpm demonstration.
+
+%prep
+%setup -q -T -c
+
+%build
+echo "Q: Why?\nA: Because we can!" > FAQ
+
+%install
+mkdir -p $RPM_BUILD_ROOT/usr/local/bin
+echo " " > $RPM_BUILD_ROOT/usr/local/bin/hello
+
+
+echo "%package docs" >>
@pmatilai commented on this pull request.
> +
+%prep
+%setup -q -T -c
+
+%build
+echo "Q: Why?\nA: Because we can!" > FAQ
+
+%install
+mkdir -p $RPM_BUILD_ROOT/usr/local/bin
+echo " " > $RPM_BUILD_ROOT/usr/local/bin/hello
+
+
+echo "%package docs" >> %{specpartsdir}/docs.specpart
+echo
@pmatilai commented on this pull request.
> @@ -273,6 +273,15 @@ static int doSetupMacro(rpmSpec spec, const char *line)
free(buf);
}
+/* mkdir for dynamic specparts */
+buf = rpmExpand("%{__mkdir} SPECPARTS", NULL);
+appendBuf(spec, buf, 1);
+free(buf);
+
+
@ffesti commented on this pull request.
> @@ -1129,3 +1157,26 @@ rpmSpec rpmSpecParse(const char *specFile,
> rpmSpecFlags flags,
{
return parseSpec(specFile, flags, buildRoot, 0);
}
+
+rpmRC parseGeneratedSpecs(rpmSpec spec)
+{
+ARGV_t argv = NULL;
+int argc = 0;
+int i;
+
> Yes, this is super ugly but nothing I am touching while adding this new
> feature. Anyone feel free to clean that up afterwards.
Do stuff for others to clean up is not an attitude us maintainers can afford
you know.
--
Reply to this email directly or view it on GitHub:
@dmnks commented on this pull request.
LGTM now, only little nitpicks, see comments.
> +layout: default
+title: rpm.org - Package Build Process
+---
+# Dynamic Spec Generation
+
+Since rpm 4.19 RPM supports parsing dynamically generated specs. This
+allows the build scripts (**%build** or
OK, fixed the error handling and added a failing test case.
Added $RPM_SPECPARTS_DIR to the build scripts and removed the true directory
name from the docs.
Turns out there is a reason that `parseSpecSection()` returns a `Spec` object:
The BUILDARCHITECTURES magic may return a different Spec
@ffesti pushed 3 commits.
a63662e1558a086a850a2da382bd7c5759a1d7ca Split actual parsing of spec into its
own function
05e784b9b576aefd88522c88ab06133048c7904d Allow starting new spec parts with
PART_EMPTY
ab78270fca71149a42fdead2b8dd14a0f2d0898c Add Dynamic Spec generation
--
View it on
@pmatilai commented on this pull request.
> @@ -273,6 +273,15 @@ static int doSetupMacro(rpmSpec spec, const char *line)
free(buf);
}
+/* mkdir for dynamic specparts */
+buf = rpmExpand("%{__mkdir} SPECPARTS", NULL);
+appendBuf(spec, buf, 1);
+free(buf);
+
+
...or maybe we should get into the habit of including these design docs in a
directory someplace in the source tree.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1485#issuecomment-1301768925
You are receiving this because you are
> Final patch might still deserve a bit longer commit message. Otoh there is
> docs on this and there is no need to duplicated that in the patch.
Yep, there's no point duplicating the user docs in the commit message. What
belongs in the commit message is a condensed version of the design spec:
@pmatilai commented on this pull request.
> @@ -1129,3 +1157,26 @@ rpmSpec rpmSpecParse(const char *specFile,
> rpmSpecFlags flags,
{
return parseSpec(specFile, flags, buildRoot, 0);
}
+
+rpmRC parseGeneratedSpecs(rpmSpec spec)
+{
+ARGV_t argv = NULL;
+int argc = 0;
+int i;
@pmatilai commented on this pull request.
> + if (checkForEncoding(pkg->header, 0) != RPMRC_OK) {
+ badenc = 1;
+ }
+ }
+ if (badenc)
+ goto errxit;
+}
+
+closeSpec(spec);
+
+exit:
+return spec;
+
+errxit:
+if (!secondary)
+
@pmatilai commented on this pull request.
> @@ -273,6 +273,15 @@ static int doSetupMacro(rpmSpec spec, const char *line)
free(buf);
}
+/* mkdir for dynamic specparts */
+buf = rpmExpand("%{__mkdir} SPECPARTS", NULL);
+appendBuf(spec, buf, 1);
+free(buf);
+
+
@dmnks commented on this pull request.
> @@ -273,6 +273,15 @@ static int doSetupMacro(rpmSpec spec, const char *line)
free(buf);
}
+/* mkdir for dynamic specparts */
+buf = rpmExpand("%{__mkdir} SPECPARTS", NULL);
+appendBuf(spec, buf, 1);
+free(buf);
+
+buf =
Oh, and apologies for the noise here, I should've raised this a while ago in
the design
[document](https://github.com/rpm-software-management/rpm/discussions/2032)
instead, and have it answered there.
--
Reply to this email directly or view it on GitHub:
There's another reason *not* to mess with the semantics of `%include`, which
is, most people likely understand it as a C preprocessor-like counterpart to
`#include`, rather than some kind of dynamic feature. Therefore separating
those two (also by using different naming conventions) is arguably
> There are a few reasons why this is not wired into `%include`. The first
> being that `%include` includes a file in place and then continues to read,
> expand and parse the rest of the file. This is something that just cannot be
> done afterwards. All kind of things could change by re-parsing
@dmnks commented on this pull request.
> + if (checkForEncoding(pkg->header, 0) != RPMRC_OK) {
+ badenc = 1;
+ }
+ }
+ if (badenc)
+ goto errxit;
+}
+
+closeSpec(spec);
+
+exit:
+return spec;
+
+errxit:
+if (!secondary)
+
There are a few reasons why this is not wired into `%include`. The first being
that `%include` includes a file in place and then continues to read, expand and
parse the rest of the file. This is something that just cannot be done
afterwards. All kind of things could change by re-parsing the
... Point being, this is just another `%include`-like mechanism, one that
happens at a very specific point during the build, yet it's completely separate
from `%include`. OTOH, as I'm writing this, I realize that maybe that's a good
thing, since the semantics of `%include` really is "include
I'm a bit late to the party, but couldn't we "just" add an `%include`
alternative (e.g. as a parameter) such that it would be parsed post-`%install`?
I'm pretty sure I'm missing some obvious reason why it couldn't be done
(easily), but I meant to ask anyway :smile:. Of course, the current
- Rebased
- Added `specpartsdir` macro
- Changed name of dir to `SPECPARTS`
- Fixed white space issues
- Use noarch package in test case
- Merged patches
Final patch might still deserve a bit longer commit message. Otoh there is docs
on this and there is no need to duplicated that in the patch.
@ffesti pushed 1 commit.
06c764a2625fe2daea62598075bac2d10fc42317 Read in spec pieces generated during
builds
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1485/files/7e43a675d518fbe41fab8c456cb73d26a95c8af3..06c764a2625fe2daea62598075bac2d10fc42317
You are
@ffesti pushed 3 commits.
ae3a952f96aa84c7eed1cd10ee86d56017a8968b Split actual parsing of spec into its
own function
28834422d628f5ad7381d18bdbb13e91dc3fc223 Allow starting new spec parts with
PART_EMPTY
7e43a675d518fbe41fab8c456cb73d26a95c8af3 Read in spec pieces generated during
builds
Hmm, so the SPECPARTS directory (whether its empty or not at the end of
%install) could be used for determining whether the feature was used during a
build, so it could be recorded as an rpmlib() dependnecy on src.rpm files
similar to DynamicBuildRequires. If we want to - we obviously do not
> Well, the sub directory is mainly there so placing specparts on older
> rpmbuild versions will fail and they won't just be silently ignored.
Yup, I got that.
> What about SPECPARTS as dir name.
It's loud, but at least it's to the point. Add a %_specpartsdir macro, point it
to that and we
> > The patch now uses a SPECS sub dir in the buildsubdir
>
> Names are hard, but this directory is nothing at all like SPECS in
> %{_topdir}, I don't think it should share that name. SPEC, maybe. Except, I
> think we may want to use such a directory for other purposes too, which is
> why the
As for the directory name: add a macro for it, and document *that* instead of
the hardcoded value. Otherwise, two weeks from the release of 4.19 we'll have a
ticket requesting for one. Been there. Also that gives us at least a fleeting
chance to rename it should such a thing be needed someday,
On the positive side, spec parse with and without this produce identical
results on texlive.spec and kernel.spec (both fairly complicated beasts),
except for the expected mkdir on the SPECS dir.
--
Reply to this email directly or view it on GitHub:
@pmatilai commented on this pull request.
> +# Check if dynamic spec generation works
+AT_SETUP([rpmbuild with dynamic spec generation])
+AT_KEYWORDS([build])
+RPMDB_INIT
+AT_CHECK([
+
+run rpmbuild --noclean\
+ -ba "${abs_srcdir}"/data/SPECS/dynamic.spec
+],
+[0],
+[ignore],
+[ignore])
+
@pmatilai commented on this pull request.
> @@ -2272,3 +2272,27 @@ runroot rpmbuild \
],
[ignore])
AT_CLEANUP
+
+# --
+# Check if dynamic spec generation works
+AT_SETUP([rpmbuild with dynamic spec generation])
+AT_KEYWORDS([build])
+RPMDB_INIT
+AT_CHECK([
+
+run
> The patch now uses a SPECS sub dir in the buildsubdir
Names are hard, but this directory is nothing at all like SPECS in %{_topdir},
I don't think it should use this name. SPEC, maybe. Except, I think we may want
to use such a directory for other purposes too, which is why the spec snippets
OK, added test case and some docs.
In addition I stripped the find-lang patch as this needs to g into it's own PR
and was only there as a demonstration piece.
The patch now uses a `SPECS` sub dir in the `buildsubdir` to allow detecting
whether the feature is supported.
I also removed the code to
@ffesti pushed 5 commits.
4320abf21b4d228b446fb679f0fa2e9f992e5985 Split actual parsing of the spec into
its own function
d8f830518e70e1bae31fab10c75720185446c5ba Allow starting new spec parts with
PART_EMPTY
29708e32c8e2fb9f2b758d97fda24f23e1506ca6 Read in spec pieces generated during
@pmatilai requested changes on this pull request.
Okay so to recoup the on-off discussions over many moons: there are further
details to sort out. While we can work on the details later, the bare minimum
requirements for merging are:
- documentation
- a test-case or two
For clarity, flagging
thanks @ffesti this groups `.mo` files by `language_id`, for example, in
`__rpmbuild_gettext-runtime.lang.specpart` :+1:
```%package lang-en@quot
Summary: en@quot translations for %{name}
%description lang-en@quot
Translations for package %{name} in en@quot
%files lang-en@quot
%lang(en@quot)
> I guess I really need to write a proper design document...
Please do.
I'm clearly thinking on somewhat different lines from you. Which is not to say
either one is wrong, just that there are so many possible scenarios that
they're easy to miss entirely, and/or don't easily fit inside ones
I guess I really need to write a proper design document...
When I think about distribution level sub package creation I think about
something very close to an brp-script - most likely a literal brp-script. Not
that I am a big fan of the way brp scripts are currently run. But I'd rather
improve
I'd think there needs to be a global switch for at least case 2, but in
addition individual scripts could/should be possible to disable case-by-case.
Which might get tricky. Of course, just `rm -f` the bits you dislike/break at
end of `%install` achieves that, but then you might want to prevent
When it comes to the distribution automagically generating sub packages I agree
that the package need to be able to over write the behaviour. But I wonder if
this really should be done on the "automatic sub packages off/on" level.
Similar to what we have with debuginfo sub packages I'd rather
Wrt implicit/explicitness of it all, it occurred to me that there are two quite
distinct cases:
1. spec invoking a script that does something - such as invoke %find_lang with
extra flags
2. upstream build system (makefiles etc) doing something
For 1. you want it to "just work" without further
And yeah, docs + a test-case or two needed. Once that is there we can do a
fine-comb review, but generally this is so remarkably tiny amount of code that
I wouldn't expect any major issues there.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly
@pmatilai commented on this pull request.
> @@ -1118,3 +1146,25 @@ rpmSpec rpmSpecParse(const char *specFile,
> rpmSpecFlags flags,
{
return parseSpec(specFile, flags, buildRoot, 0);
}
+
+rpmRC parseGeneratedSpecs(rpmSpec spec)
+{
+
+ARGV_t argv = NULL;
+int argc = 0;
+
It would be nice to see some simple example(s) :-)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@ffesti pushed 3 commits.
b7b472b3e4ff284e260a581749c6fb30f24f38cc Parse spec snippets before running
%check
3e4d486e415f603b2403eae7faa8a5325eedf39e Use __rpmbuild_*.specpart in BUILDDIR
instead of __rpm sub dir
ce3c6e97be69c6febcd3fd2f6424099eb8e7bdd2 Add support for
> Is there a reason we can't just push it back into `rpmbuild` itself directly?
> Like perhaps by exposing something via Lua that lets you programmatically
> define binary packages?
Yes, we could. I have thinking about this quite a lot. But this is much more
complicated and harder to use.
> Do I understand it correctly that you'd essentially do a `my_spec_generator >
> %_builddir/__rpm/subpac.spec` which would e.g. contain a new subpackage
> definition?
Basically yes. As this is run in the %build or %install section you would need
to modify your spec generator to not output
> * The generated spec fragments need to have some other suffix than *.spec to
> avoid confusion. Call it .specpart or whatever, but they are not spec files
> so they must not be mistaken as such, either by humans or the computer (eg
> multiple .spec files in a tarball will confuse rpm)
> * If
This looks intriguing!
Do I understand it correctly that you'd essentially do a `my_spec_generator >
%_builddir/__rpm/subpac.spec` which would e.g. contain a new subpackage
definition?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it
cc: @dcermak
--
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/1485#issuecomment-760169523___
Rpm-maint mailing list
More random thoughts as they trickle through this old-but-not-obsolete (yet)
processor of mine... :brain:
- This is too implicit as it is. Existing carefully hand-crafted packages can't
start behaving differently because somebody else somewhere did something
(unless that something creates new
A couple of random thoughts:
- I think we'd want the generated specs parse occur before `%check` because you
want to get possible packaging errors as soon as possible, and test-suites can
take significant amount of time. And actually, I don't think we should allow
`%check` to affect the actual
Didn't look with a microscope yet (some whitespace and spelling issues there at
least) but on the whole this looks really neat set of patches. Which is usually
a good sign :+1:
Do add some test-case(s) though, no matter how artificial.
--
You are receiving this because you are subscribed to
cc @davide125
--
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/1485#issuecomment-758602337___
Rpm-maint mailing list
@ffesti pushed 1 commit.
89402a09e08d19c93cbd800e7ba53814f0c90aac Remove stupid warning
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
This is an alternative to #1239
Instead of extending the spec syntax with dynamic elements allow the build
process to generate their own spec file snippets that get read in after
executing `%build` (technically after `%check`) from `$BUILDDIR/__rpm/*.spec`.
This allows tricks like generating
91 matches
Mail list logo
