Sorry for the holdup folks, I've been mulling over this quite a bit. The tests
that is.
The test-suite is a deal-breaker really. Rpm's test-suite is the autotest-based
thing, and everything in rpm needs to use that for tests. We can't have
individual bits and pieces bring in their own infra, de
@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)) {
+
An idea related to #1225 and various other dynamic spec generation macro items
etc.
Currently when a spec section is closed, there's no returning to that. %end
doesn't help with that as it just enters a no-mans land where only comments and
macro definitions may live.
One possibility would be a
@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 get
Yup - the point being, parsing the spec simply can not require generating any
directories. If it does, something is very wrong :)
--
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
Maybe %prep/%build/%install could simply take an optional name as an argument,
just like %package, %files etc do? And actually execute them separately if
defined that way. Seems it'd simplify eg conditional sub-packaging quite a bit.
--
You are receiving this because you are subscribed to this
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
makes sense, I can rework tarball case to create tempdir and set _specdir
there. I guess we can drop creation of sourcedir as well.
--
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/r
> So rpm would need to invent something, but how does the callee then know how
> to locate that when it was rpm that invented it
@pmatilai Thank you for any changes. Please keep in mind that it was originally
requested in bugzilla, and we would like to use it in next RHEL.
> You need to start w
@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:re
@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", 5)
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:
https://github.com/rpm-software-management/rpm/pull/1239#issuecomment-633491347
There's also the question whether it should be creating %_specdir and
%_sourcedir at all, as these need to pre-exist anyway. Except for tarbuild, and
the reason tar-build "needs" %_specdir is also dubious, it could just as well
use the current (or temporary) just as it does with %_sourcedir.
T
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.
Th
@pmatilai you wrote:
> In other words, GPLv2.
That's what I thought (with some hope it would be LGPL like for librpm)
> The license should be specified in the Python distutils module description
> though, so thanks for reporting.
That would be a nice improvement for clarity! Thank you!
--
Yo
@pmatilai FYI, this case have been fixed. This PR works fine from my testing.
Sorry, forgot to type this before :)
--
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/1235#issu
The python bindings are part of the rpm source tree, hence COPYING applies:
> The entire code base may be distributed under the terms of the GNU General
Public License (GPL), which appears immediately below. Alternatively,
all of the source code in the lib and rpmio subdirectories of the RPM sour
Fixes: #1236
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/1238
-- Commit Summary --
* Add license to Python distutils module description
-- File Changes --
M python/setup.py.in (1)
-- Patch Links --
https://github
Yup, the tarball case is an annoying one.
--
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/1235#issuecomment-633415937___
Rpm-main
Fix what?
If you mean the "key" argument to addErase(), it's not a simple thing. It's not
an optional "data" argument that you're passing to addInstall/addReinstall, but
a key which gets passed back to you for the purpose of opening the package file
when the time comes. There's nothing similar
20 matches
Mail list logo
