Re: [Rpm-maint] [rpm-software-management/rpm] RFE: introduce an rpm-controlled per-build directory to builds (Issue #2078)
Making remote execution (cross-compilation) easier added (inspired by https://github.com/rpm-software-management/rpm/discussions/2884) -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2078#issuecomment-1928947972 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Support for running %check on a different machine (Discussion #2884)
Oh. Reading more carefully now, I can see a lack of "the" and a relevant plural
in "running test suites" :sweat_smile: Adjusted the title to make it clear.
All the build scriptlets have (some) support for remote execution through this:
> %___build_cmd %{?_sudo:%{_sudo} }%{?_remsh:%{_remsh} %{_remhost}
> }%{?_remsudo:%{_remsudo} }%{?_remchroot:%{_remchroot} %{_remroot}
> }%{___build_shell} %{___build_args}
It requires setting up some shared mounts of course (for %_tmpdir and the build
area at least), I've never tried that in practise.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2884#discussioncomment-8378969
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Support for running tests on a different machine (Discussion #2884)
@pmatilai I was referring to `%check` in spec files, _not_ RPM’s own test suite (though that would be useful too). -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2884#discussioncomment-8374826 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RPM 4.19.1.1 bugfix update (PR #2888)
I confirmed that this still builds on macOS, using [these commands](https://github.com/rpm-software-management/rpm/issues/2807#issuecomment-1877296382)–the only difference being that I added `readline` to `PKG_CONFIG_PATH` like this: `PKG_CONFIG_PATH=/usr/local/opt/libarchive/lib/pkgconfig:/usr/local/opt/readline/lib/pkgconfig` So this looks great to me -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2888#issuecomment-1927664713 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Introduce an rpm-controlled per-build directory (PR #2885)
Just found in inbox that another maintainer sorted out issue related to create directory in python module source tree https://github.com/PyGithub/PyGithub/pull/2894. As you see fixing that it is not rocket science .. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2885#issuecomment-1927414807 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Introduce an rpm-controlled per-build directory (PR #2885)
Just made grep across all Fedora spec files
```console
[tkloczko@pers-jacek SPECS.fedora]$ grep SPECPARTS *
python-bidict.spec:# SPECPARTS dir in %%_builddir/%%buildsubdir is leaking to
setuptools package
python-bidict.spec:rm -rf SPECPARTS
python-cairocffi.spec:- Drop rmdir SPECPARTS
python-chaospy.spec:rm -rf SPECPARTS
python-linkify-it-py.spec:- Stop removing the SPECPARTS directory, it doesn't
exist
python-linkify-it-py.spec:- Remove empty SPECPARTS directory that breaks build
python-mechanize.spec:rm -rf SPECPARTS
python-neo.spec:# remove rpm's SPECPARTS file
python-neo.spec:rm -rf SPECPARTS
python-nihtest.spec:# Work around issue with package discovery due to SPECPARTS
dir
python-nose2.spec:rm -rf SPECPARTS
python-numpoly.spec:rm -rf SPECPARTS
python-quantities.spec:# Work around confusion with SPECPARTS directory looking
like a package to
python-quantities.spec:rm -rf SPECPARTS
python-uc-micro-py.spec:rm -rf SPECPARTS
qcad.spec:rm -rf ../*-SPECPARTS
rpm.spec:- Use mkdir -p for creating SPECPARTS dir
traceroute.spec:%make_build CFLAGS="$RPM_OPT_FLAGS" LDFLAGS="$RPM_LD_FLAGS"
SKIPDIRS="${RPM_SPECPARTS_DIR##*/}"
```
Few of those cases already have been sorted out by source tree maintainers.
Another question is .. is it really worth to keep SPECPARTS extension in rpm? 樂
So far not been able to find even SINGLE case of use that.
IMO that whole SPECPARTS created so far more issues (and by this wasted more
man/hours) than saved any time on packaging.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2885#issuecomment-1927384811
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Introduce an rpm-controlled per-build directory (PR #2885)
> Do I understand correctly that the `BUILDROOT` dir was replaced by
> `%{_builddir}/%{_target_cpu}-%{_target_os}-root`? The `%{_builddir}` is the
> right move IMHO, but what is the advantage of
> `%{_target_cpu}-%{_target_os}-root` over `BUILDROOT`, especially when e.g.
> `SPECPARTS` stays the same.
I'm using below patch
```patch
--- a/tests/rpmspec.at
+++ b/tests/rpmspec.at
@@ -333,8 +333,8 @@
exit $STATUS
fi
cd 'hello-1.0'
-rm -rf '/build/BUILD/hello-1.0-SPECPARTS'
-/usr/bin/mkdir -p '/build/BUILD/hello-1.0-SPECPARTS'
+rm -rf '/build/BUILD/hello-1.0/SPECPARTS'
+/usr/bin/mkdir -p '/build/BUILD/hello-1.0/SPECPARTS'
/usr/bin/chmod -Rf a+rX,u+w,g-w,o-w .
echo "Patch #0 (hello-1.0-modernize.patch):"
/usr/bin/patch --no-backup-if-mismatch -f -p1 -b --suffix .modernize --fuzz=0
< /build/SOURCES/hello-1.0-modernize.patch
--- a/macros.in
+++ b/macros.in
@@ -271,7 +271,7 @@
%buildroot %{_buildrootdir}/%{NAME}-%{VERSION}-%{RELEASE}.%{_arch}
# Path for spec file snippets generated during build
-%specpartsdir %{_builddir}/%{buildsubdir}-SPECPARTS
+%specpartsdir %{_builddir}/%{buildsubdir}/SPECPARTS
# Directory where temporaray files can be created.
%_tmppath %{_var}/tmp
--- a/build/build.c
+++ b/build/build.c
@@ -195,14 +195,8 @@
fprintf(fp, "cd '%s'\n", buildSubdir);
if (what == RPMBUILD_RMBUILD) {
- if (rpmMacroIsDefined(spec->macros, "specpartsdir")) {
- char * buf = rpmExpand("%{specpartsdir}", NULL);
- fprintf(fp, "rm -rf '%s'\n", buf);
- free(buf);
- }
if (buildSubdir[0] != '\0')
- fprintf(fp, "rm -rf '%s' '%s.gemspec'\n",
- buildSubdir, buildSubdir);
+ fprintf(fp, "rm -rf '%s'\n", buildSubdir);
} else if (sb != NULL)
fprintf(fp, "%s", sb);
```
After that I've tested that whit almost 5k of my src.rpm and found that only
few packages are failing because of that change.
All those packages are python modules and fail s result of MISSING parts in
pyprojects toml.
Because SPECPARTS **exposed those issue** IMO instead evacuating that directory
outside source tree it should be INTENTIONALLY put in that location.
In meantime for all those cases I've opened issue tickets and ~half already
have been sorted out.
Example fail on building `uc-micro-py` python module:
```console
+ /usr/bin/python3 -sBm build -w --no-isolation
* Getting build dependencies for wheel...
No `packages` or `py_modules` configuration, performing automatic discovery.
`flat-layout` detected -- analysing .
discovered packages -- ['uc_micro', 'SPECPARTS ', 'uc_micro.categories',
'uc_micro.properties', 'uc_micro.categories.Cc', 'uc_micro.categories.Cf',
'uc_micro.categories.P', 'uc_micro.categories.Z', 'uc_micro.properties.Any']
Traceback (most recent call last):
File
"/usr/lib/python3.8/site-packages/pyproject_hooks/_in_process/_in_process.py",
line 353, in
main()
File
"/usr/lib/python3.8/site-packages/pyproject_hooks/_in_process/_in_process.py",
line 335, in main
json_out['return_val'] = hook(**hook_input['kwargs'])
File
"/usr/lib/python3.8/site-packages/pyproject_hooks/_in_process/_in_process.py",
line 118, in get_requires_for_build_wheel
return hook(config_settings)
File "/usr/lib/python3.8/site-packages/setuptools/build_meta.py", line 325,
in get_requires_for_build_wheel
return self._get_build_requires(config_settings, requirements=['wheel'])
File "/usr/lib/python3.8/site-packages/setuptools/build_meta.py", line 295,
in _get_build_requires
self.run_setup()
File "/usr/lib/python3.8/site-packages/setuptools/build_meta.py", line 311,
in run_setup
exec(code, locals())
File "", line 1, in
File "/usr/lib/python3.8/site-packages/setuptools/__init__.py", line 103, in
setup
return distutils.core.setup(**attrs)
File "/usr/lib/python3.8/site-packages/setuptools/_distutils/core.py", line
159, in setup
dist.parse_config_files()
File "/usr/lib/python3.8/site-packages/setuptools/dist.py", line 627, in
parse_config_files
pyprojecttoml.apply_configuration(self, filename, ignore_option_errors)
File "/usr/lib/python3.8/site-packages/setuptools/config/pyprojecttoml.py",
line 66, in apply_configuration
config = read_configuration(filepath, True, ignore_option_errors, dist)
File "/usr/lib/python3.8/site-packages/setuptools/config/pyprojecttoml.py",
line 131, in read_configuration
return expand_configuration(asdict, root_dir, ignore_option_errors, dist)
File "/usr/lib/python3.8/site-packages/setuptools/config/pyprojecttoml.py",
line 156, in expand_configuration
return _ConfigExpander(config, root_dir, ignore_option_errors,
dist).expand()
File "/usr/lib/python3.8/site-packages/setuptools/config/pyprojecttoml.py",
line 204, in expand
self._expand_all_dynamic(dist, package_dir)
File "/usr/lib/python3.8/site-packages/setuptools/config/pyprojecttoml.py",
line 249, in _expand_all_dynamic
Re: [Rpm-maint] [rpm-software-management/rpm] Proof-of-concept native support for vpath-style builds (PR #2886)
I am not sure if tying this to the `%setup` is useful, unless there is also
some alternative to setup this independently. Maybe if the `%{-s}` also
accepted some alternative build name(s).
> A one gotcha here is that special %doc and %license has traditionally worked
> for both built and pre-existing content.
The files could be gathered in `%{sourcesubdir}` followed by `%{buildsubdir}`,
why not. But how often is the documentation build? It never came to my mind
that the documentation could be generated during build and I wouldn't mind if
only the former was possible. Or actually if neither one worked and the
documentation would need to be installed into `%{_buildrootdir}` manually.
BTW this does not update the `make` macros, right? Which are likely more noisy
then the `configure` itself. IOW on one `./configure` call, there are typically
two make calls, such as `make` and `make install`
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2886#issuecomment-1927267885
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Introduce an rpm-controlled per-build directory (PR #2885)
Do I understand correctly that the `BUILDROOT` dir was replaced by
`%{_builddir}/%{_target_cpu}-%{_target_os}-root`? The `%{_builddir}` is the
right move IMHO, but what is the advantage of
`%{_target_cpu}-%{_target_os}-root` over `BUILDROOT`, especially when e.g.
`SPECPARTS` stays the same.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2885#issuecomment-1927215228
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Is there a way to merge several RPMs (Discussion #2887)
> > > You are also kinda confused about RPMs and SRPMs. > > > > > > I don't think I am. Or at least I don't know why you think so. > > That's what a confused person would say... :rofl: :man_facepalming: 路 > Merging RPMs and SRPMs is not something we will pursue and it doesn't make > any sense. There is no point in merging SRPMs as they can only have one spec > file each. > > > If you do want to merge binary packages (not that I can think of a good > > > reason) use meta packages instead. > > > > > > This is not an option in this context. One way or the other, it adds one > > more package. > > I have not yet seen an argument why the number of packages is a problem. There was modularity, but it is not anymore. Now I am thinking what to use instead. In the case of Ruby, the module consisted of Ruby and DB connectors. We can simplify this into having `ruby` and `rubygem-pg` SRPMs, which in it full fledge state builds into gazillion RPMs subpackages, and call it "default Ruby". Now I am considering options how to deliver some alternative version. One of the options is lump everything together and deliver it as a single RPM (instead of all the subpackages which "default ruby" consists of). Of course I could ignore everything what is already available and start from scratch. The other option is to try gather various bits and pieces and try to reuse them. > > > Merging Spec files is a different thing completely. That is probably > > > something to look into - especially if they can be created automatically > > > from gems or similar language specific package formats. > > > > > > This is what I thought would be the hard part Maybe mainly because I > > don't see a merit in merging spec files like just plain concatenating and > > obtaining the same result. It would probably be interesting, if I can > > select some sections, while probably modify the associated `%files` section. > > This is the only thing here that is actually worth considering here. It would > kinda fit into both the Dynamic Spec and the Handsfree Packaging initiatives. > Basically dropping multiple gems into a single distgit package and assemble > the merged spec file automatically. There are probably still a few pieces > missing but we already made big steps into making this possible. Nice. Still to me, merging RPMs sounds easier then merging .spec files. To me, merging RPMs happens every time two RPMs are installed. Of course I ignore metadata. But I have never heard of merging .spec files. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2887#discussioncomment-8370983 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RPM 4.19.x bugfix release (Issue #2878)
> * [Print full path if file removal fails > #2806](https://github.com/rpm-software-management/rpm/pull/2806) Just FTR, this one already is in 4.19.1. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2878#issuecomment-1927097817 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] RPM 4.19.1.1 bugfix update (PR #2888)
This is a small bugfix-only update addressing a number of regressions and other issues. A changelog preview follows: Fixes * *Packaging:* Dont warn about missing user/group on skipped files supRegression/sup ([#2814](https://github.com/rpm-software-management/rpm/pull/2814)) * *Packaging:* Make user/group lookup caching thread-safe supRegression/sup ([#2843](https://github.com/rpm-software-management/rpm/pull/2843)) * *Lua interface:* Fix regression in Lua scriptlet runaway child detection supRegression/sup ([#2818](https://github.com/rpm-software-management/rpm/pull/2818)) * *Build:* CMakeLists.txt: restore readline support as an explicit option supRegression/sup ([#2852](https://github.com/rpm-software-management/rpm/pull/2852)) * *Build:* Fix unconditional uses of Linux-specific extensions supRegression/sup ([#2812](https://github.com/rpm-software-management/rpm/pull/2812)) * *Build:* Add missing include for check_symbol_exists ([#2831](https://github.com/rpm-software-management/rpm/pull/2831)) * *Build:* Dont use _nl_msg_cat_cntr if its not available ([#2856](https://github.com/rpm-software-management/rpm/pull/2856)) Resolves: #2878 You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/2888 -- Commit Summary -- * Dont warn about missing user/group on skipped files * Fix markdown formatting in man page * Fix regression in Lua scriptlet runaway child detection * Fix hard dependency on libelf (cmake transition fallout) * Fix hard dependency on strchrnul() GNU extension * Fix unconditional dependency on non-POSIX GLOB_ONLYDIR flag * Fix rpm2archive build regression due to missing libgen.h include * Fix missing private linkage to iconv and popt in librpmbuild and sign * Conditionalize libdw and libelf linkage to librpmbuild * Cosmetics: fix rpmio cmake indentation style * Fix libintl linkage and include directories (cmake transition fallout) * Drop unnecessary rpmcli.h include from rpmbuild.h * rpmcli.h forces a public dependency on popt includes * Add missing include * Dont attempt to install html pages if theyre not built * CMakeLists.txt: restore readline support as an explicit option * Remember to free user/group cache on librpm shutdown (again) * Centralize user/group lookup caching into a single data structure * Make user/group lookup caching minimally thread-safe * Simplify the cache lookup logic, no functional changes * Dont use _nl_msg_cat_cntr if its not available * Use unsigned integers for buildtime too for Y2K38 safety * Fix a theoretical use of uninitialized struct members * Add a note about rpmfiFN()/rpmfiOFN() pointer validity to API docs * Preparing for rpm 4.19.1.1 -- File Changes -- M CMakeLists.txt (17) M build/CMakeLists.txt (16) M build/build.c (4) M config.h.in (2) M docs/CMakeLists.txt (5) M docs/man/rpmdb.8.md (2) M include/rpm/rpmbuild.h (1) M include/rpm/rpmfi.h (2) M lib/CMakeLists.txt (5) M lib/fsm.c (2) M lib/rpmrc.c (2) M lib/rpmscript.c (2) M lib/rpmug.c (126) M lib/tagexts.c (6) M misc/CMakeLists.txt (1) M plugins/CMakeLists.txt (4) M rpmio/CMakeLists.txt (13) M rpmio/rpmglob.c (2) M rpmio/rpmlua.c (10) M sign/CMakeLists.txt (2) M tests/rpmgeneral.at (8) M tests/rpmmacro.at (9) M tests/rpmsigdig.at (6) M tools/CMakeLists.txt (20) M tools/rpm2archive.c (5) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/2888.patch https://github.com/rpm-software-management/rpm/pull/2888.diff -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2888 You are receiving this because you are subscribed to this thread. Message ID: rpm-software-management/rpm/pull/2...@github.com ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] support reproducible automatic rebuilds (PR #2880)
> Steps to reproduce: > >package gcc: version 1.1 >package hello: BuildDepends gcc; changelog epoch 1; but its build script > includes SOURCE_DATE_EPOCH in the binary >build package hello >update package gcc to version 1.2 >[...] I get that this is the real-world scenario, but we'd need something much, MUCH simpler for the test-suite. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2880#issuecomment-1926944167 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Is there a way to merge several RPMs (Discussion #2887)
> > You are also kinda confused about RPMs and SRPMs. > > I don't think I am. Or at least I don't know why you think so. That's what a confused person would say... Merging RPMs and SRPMs is not something we will pursue and it doesn't make any sense. There is no point in merging SRPMs as they can only have one spec file each. > > If you do want to merge binary packages (not that I can think of a good > > reason) use meta packages instead. > > This is not an option in this context. One way or the other, it adds one more > package. I have not yet seen an argument why the number of packages is a problem. > > Merging Spec files is a different thing completely. That is probably > > something to look into - especially if they can be created automatically > > from gems or similar language specific package formats. > > This is what I thought would be the hard part Maybe mainly because I don't > see a merit in merging spec files like just plain concatenating and obtaining > the same result. It would probably be interesting, if I can select some > sections, while probably modify the associated `%files` section. This is the only thing here that is actually worth considering here. It would kinda fit into both the Dynamic Spec and the Handsfree Packaging initiatives. Basically dropping multiple gems into a single distgit package and assemble the merged spec file automatically. There are probably still a few pieces missing but we already made big steps into making this possible. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2887#discussioncomment-8369464 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Support for running tests on a different machine (Discussion #2884)
@dmnks feel free to correct/extend, but the test-suite does run as a separate step in the "native" mode using already built binaries. That's only supported on Fedora at the moment but that's AIUI just a matter of somebody adding + maintaining a native dockerfile for their target distro. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2884#discussioncomment-8369228 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Is there a way to merge several RPMs (Discussion #2887)
> You are also kinda confused about RPMs and SRPMs. I don't think I am. Or at least I don't know why you think so. One possibility I can think of is that if the RPMs should be mergeable, then probably also SRPM should be mergeable for consistency? That would be likely weird, not sure 路 > I don't think you really want to merge binary RPMs but get rid of packages in > distgit - which is the expensive part as far as I see it. Maybe or maybe not. I am looking for options. > If you do want to merge binary packages (not that I can think of a good > reason) use meta packages instead. This is not an option in this context. One way or the other, it adds one more package. > Merging Spec files is a different thing completely. That is probably > something to look into - especially if they can be created automatically from > gems or similar language specific package formats. This is what I thought would be the hard part Maybe mainly because I don't see a merit in merging spec files like just plain concatenating and obtaining the same result. It would probably be interesting, if I can select some sections, while probably modify the associated `%files` section. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2887#discussioncomment-8369215 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Is there a way to merge several RPMs (Discussion #2887)
Even longer answer: One could create a tool to do that with the rpm API. But I really don't see a a reason to do so. You are also kinda confused about RPMs and SRPMs. I don't think you really want to merge binary RPMs but get rid of packages in distgit - which is the expensive part as far as I see it. If you do want to merge binary packages (not that I can think of a good reason) use meta packages instead. Merging Spec files is a different thing completely. That is probably something to look into - especially if they can be created automatically from gems or similar language specific package formats. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2887#discussioncomment-8368898 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Is there a way to merge several RPMs (Discussion #2887)
Short answer: No Longer answer: No, but one could create one, but you really do not want to. Other answer: Yes, but no the way you want. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2887#discussioncomment-8368857 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Introduce an rpm-controlled per-build directory (PR #2885)
FWIW, the %{NAME}-%{VERSION}-PKG name is not really intended as final, I used
that just to have it stand out from the logs. Better ideas welcome.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2885#issuecomment-1926715511
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Proof-of-concept native support for vpath-style builds (PR #2886)
Besides PoC, this is of course rather simple-minded too. There may be some interesting possibilities in supporting multiple build variants natively here. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2886#issuecomment-1926707782 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Introduce an rpm-controlled per-build directory (PR #2885)
@pmatilai pushed 1 commit. 80a60aa2bddb78a897e6279891ec58d862d92d74 fixup! Introduce an rpm-controlled per-build directory -- View it on GitHub: https://github.com/rpm-software-management/rpm/pull/2885/files/2e18582771df083726278bc64feee8b8b5268e74..80a60aa2bddb78a897e6279891ec58d862d92d74 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Is there a way to merge several RPMs (Discussion #2887)
This is related to https://github.com/rpm-software-management/rpm/discussions/2849#discussioncomment-8368400. Given there are a.rpm and b.rpm packages, is there a way to merge them into package c.rpm (or merge b.rpm into a.rpm, it does not matter). -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2887 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Proof-of-concept native support for vpath-style builds (PR #2886)
This is on top of the per-build directory PR because it makes this much easier to do, ie the actual feature here is just the last commit. This is NOT meant for merging at this point, just that even a crude implementation is easier to discuss than thin air. See also https://github.com/rpm-software-management/rpm/discussions/2882 -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2886#issuecomment-1926674899 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Package specific prep/build/... sections (Discussion #2849)
Just FTR, this is related to the #2847. What I am possibly about to do is to package Ruby with a few gems into single binary RPM. So my high level idea is to essentially "join" Ruby .spec file with the .spec files of the gems. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2849#discussioncomment-8368400 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Package specific prep/build/... sections (Discussion #2849)
> Append/prepend is still operating on exactly one script of a type. Maybe it could stay like that in practice, if you are talking about the underlying bash script (which to me is just implementation detail I deliberately ignore) > With append/prepend, you can place sub-package specific build scriptlet > sections into their own sections though, so you can have a single %if/%endif > around it all. Possibly, while I can't really imagine it lacking real experience. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2849#discussioncomment-8368363 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Proof-of-concept native support for vpath-style builds (PR #2886)
Add a new %setup switch -s to indicate building in a directory outside the
source directory, known as vpath build in some circles. Add a new
%{sourcesubdir} macro which by default equals %{buildsubdir}, but when -s is
used, we create and switch to a separate directory after unpacking.
A one gotcha here is that special %doc and %license has traditionally worked
for both built and pre-existing content. With build and source trees separated,
both cannot work. As special %doc/%license is mostly used for things like
READMEs and COPYING which come as part of the source, we define %doc on
vpath builds to mean source directory, and assume built content has its own
means of installing (eg make install-doc).
Another potential issue is that we redefine %_configure to an absolute path in
the sourcesubdir, this would break some unusual cases where %configure is used
to invoke a configure-script outside the project top directory. Its mainly
redefined here to make testing -s on an autotools project easy, a final
implementation might do something else.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/2886
-- Commit Summary --
* Introduce an rpm-controlled per-build directory
* Make buildroot fully rpm controlled, always inside the per-build directory
* Move SPECPARTS to per-pkg builddir, no longer needing name-version
* PoC: Add native support for vpath-style builds outside the source tree
-- File Changes --
M build/build.c (38)
M build/files.c (2)
M build/parsePreamble.c (30)
M build/parsePrep.c (20)
M build/parseSpec.c (15)
M build/rpmbuild_internal.h (1)
M build/spec.c (4)
M include/rpm/rpmbuild.h (3)
M macros.in (22)
M tests/rpmbuild.at (46)
M tests/rpmspec.at (8)
M tools/rpmbuild.c (18)
-- Patch Links --
https://github.com/rpm-software-management/rpm/pull/2886.patch
https://github.com/rpm-software-management/rpm/pull/2886.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2886
You are receiving this because you are subscribed to this thread.
Message ID: rpm-software-management/rpm/pull/2...@github.com
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Introduce an rpm-controlled per-build directory (PR #2885)
@pmatilai pushed 2 commits. beeb017d5f471aa5572f5c18365ece89cce8ebd0 Make buildroot fully rpm controlled, always inside the per-build directory 2e18582771df083726278bc64feee8b8b5268e74 Move SPECPARTS to per-pkg builddir, no longer needing name-version -- View it on GitHub: https://github.com/rpm-software-management/rpm/pull/2885/files/18b31fd7cb9ebf3e2d656013935e68ac78320482..2e18582771df083726278bc64feee8b8b5268e74 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Introduce an rpm-controlled per-build directory (PR #2885)
In our ancient wacko setup, %_builddir is shared by all your packages, under
which a package may create %buildsubdir - if it uses %setup that is. In other
words, theres no safe and sane place for rpm to place per-build material.
Introduce a new intermediate directory between the two, created in a newly
added (internal) %builddir build step, to give rpm that place. This opens up
all manner of opportunities, to be explored in later commits.
A new build-time macro %pkgbuilddir is added for the absolute path of this new
directory, but in addition we override %_builddir to the same value for maximum
compatibility with existing specs - a LOT of packages reference %{_builddir}
for all sorts of (mostly bad) reasons and we dont want to deal with the
carnage that would follow from breaking it. A further complication here is that
defining %_builddir (along with sources etc) to current working directory is a
common configuration (used eg by fedpkg and its variants) that we dont
want to break either. So upon entry, we grab the pre-existing %_builddir and
define %_top_builddir from it, which we can then base the %pkgbuilddir on,
while preserving compatibility with both of the above scenarios.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/2885
-- Commit Summary --
* Introduce an rpm-controlled per-build directory
-- File Changes --
M build/build.c (29)
M build/parsePreamble.c (13)
M build/rpmbuild_internal.h (1)
M build/spec.c (4)
M include/rpm/rpmbuild.h (1)
M macros.in (8)
M tests/rpmbuild.at (32)
M tests/rpmspec.at (6)
M tools/rpmbuild.c (6)
-- Patch Links --
https://github.com/rpm-software-management/rpm/pull/2885.patch
https://github.com/rpm-software-management/rpm/pull/2885.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2885
You are receiving this because you are subscribed to this thread.
Message ID: rpm-software-management/rpm/pull/2...@github.com
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Native support for separate build and source tree (aka vpath builds) (Discussion #2882)
Good point wrt multiple build directories :+1: While we have native support for these kind of multiple variants builds via `RemovePathPostfixes` (which isn't used by vim or python in fedora, curl does though), having separate build and buildroot directories could make that easier to use. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2882#discussioncomment-8367139 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Package specific prep/build/... sections (Discussion #2849)
Append/prepend is still operating on exactly one script of a type. Adding support for multiple scripts for each step would be a huge amount of work for very little benefit, I don't see that happening. With append/prepend, you can place sub-package specific build scriptlet sections into their own sections though, so you can have a single %if/%endif around it all. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2849#discussioncomment-8366986 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
