[Rpm-maint] [rpm-software-management/rpm] Is there a way to detect `SRPM` / `RPM` build? (Discussion #3046)
Looking at the dynamic spec, specifically at
5d288554719095d1c67fd87cad65224743152d06, it is silly that the `FULLDYNAMIC` is
external information. If it was possible to distinguish the `SRPM` / `RPM`
build, it would be more interesting. E.g. if there was `_srpm_build` macro
defined during the SRPM build, this could be immediately interesting:
~~~diff
$ git diff
diff --git a/dynamic.spec b/dynamic.spec
index d46a5c4..f86de2e 100644
--- a/dynamic.spec
+++ b/dynamic.spec
@@ -2,12 +2,12 @@ Name: dynamic
Version: 1.0
Release: 1
BuildArch: noarch
-%{?!FULLDYNAMIC:
+%{?_srpm_build:
Group: Utilities
License: GPL
Distribution: RPM test suite.
URL: http://rpm.org
-Summary: dynamic hello -- hello, world rpm
+Summary: source dynamic hello -- hello, world rpm
}
%description
@@ -23,13 +23,11 @@ echo "Q: Why?\nA: Because we can!" > FAQ
mkdir -p $RPM_BUILD_ROOT/usr/local/bin
echo " " > $RPM_BUILD_ROOT/usr/local/bin/hello
-%{?FULLDYNAMIC:
echo "Group: Utilities" >> %{specpartsdir}/mainpkg.specpart
echo "License: GPL" >> %{specpartsdir}/mainpkg.specpart
echo "Distribution: RPM test suite." >> %{specpartsdir}/mainpkg.specpart
echo "URL: http://rpm.org; >> %{specpartsdir}/mainpkg.specpart
-echo "Summary: dynamic hello -- hello, world rpm" >>
%{specpartsdir}/mainpkg.specpart
-}
+echo "Summary: binary dynamic hello -- hello, world rpm" >>
%{specpartsdir}/mainpkg.specpart
echo "%package docs" >> %{specpartsdir}/docs.specpart
%{?!FAIL:echo "Summary: Documentation for dynamic spec" >>
%{specpartsdir}/docs.specpart}
~~~
So is there a way to detect the SRPM build?
BTW does this feature enable to build SRPM without the `Summary` / `License`
information? Is that intentional?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/3046
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] Dynamic spec for main package does not work (Issue #3038)
Ah, right, there is rpm-4.20.0-alpha tag. I was somehow under impression that this should have been already in Rawhide. Sorry for the noise. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3038#issuecomment-2061313183 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] Dynamic spec for main package does not work (Issue #3038)
**Describe the bug**
Trying to reproduce the test case from 5d288554719095d1c67fd87cad65224743152d06
it fails for me:
**To Reproduce**
Steps to reproduce the behavior:
1.
~~~
$ cat SPECS/dynamic.spec
Name: dynamic
Version: 1.0
Release: 1
BuildArch: noarch
%{?!FULLDYNAMIC:
Group: Utilities
License: GPL
Distribution: RPM test suite.
URL: http://rpm.org
Summary: dynamic hello -- hello, world rpm
}
%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
%{?FULLDYNAMIC:
echo "Group: Utilities" >> %{specpartsdir}/mainpkg.specpart
echo "License: GPL" >> %{specpartsdir}/mainpkg.specpart
echo "Distribution: RPM test suite." >> %{specpartsdir}/mainpkg.specpart
echo "URL: http://rpm.org; >> %{specpartsdir}/mainpkg.specpart
echo "Summary: dynamic hello -- hello, world rpm" >>
%{specpartsdir}/mainpkg.specpart
}
echo "%package docs" >> %{specpartsdir}/docs.specpart
%{?!FAIL:echo "Summary: Documentation for dynamic spec" >>
%{specpartsdir}/docs.specpart}
echo "BuildArch: noarch" >> %{specpartsdir}/docs.specpart
echo "%description docs" >> %{specpartsdir}/docs.specpart
echo "Test for dynamically generated spec files" >>
%{specpartsdir}/docs.specpart
echo "%files docs" >> $RPM_SPECPARTS_DIR/docs.specpart
echo "%doc FAQ" >> $RPM_SPECPARTS_DIR/docs.specpart
%files
%defattr(-,root,root)
%attr(0751,root,root) /usr/local/bin/hello
%changelog
* Mon Oct 24 2022 Florian Festi
- create.
~~~
2.
~~~
$ rpmbuild -D "FULLDYNAMIC 1" -ba SPECS/dynamic.spec
error: Summary field must be present in package: (main package)
error: License field must be present in package: (main package)
~~~
**Expected behavior**
The test above passes and can build binary RPMs
**Environment**
- OS / Distribution: Fedora Rawhide
- Version: rpm-4.19.1.1-1.fc40.x86_64
**Additional context**
This makes me wonder if the test case is correct and if it does not test output
of other command by accident.
In any case, the test does not try to test the header, it keeps testing the
-docs. That does not seem to be right.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3038
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] Meta programming in .spec using Lua, is it heresy? (Discussion #2969)
This would actually address #1225 -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2969#discussioncomment-9119090 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] Add support for bare `%package` (Discussion #2959)
I don't know anything about Debian, but yes, having binary package of different name is one of the motivations. But to me, this is optional depending if this scenario was supported. Nonetheless, I think that being able to define subpackages before preamble is beneficial on itself and it would help to remove hacks such as: https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/b7d1bfae1fb673c4d8a21a8866ba4e37b2cd6eaf/f/common.lua#_217-235 (and it does not mean that I necessarily defend purpose and implementation of those macros) -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2959#discussioncomment-8975559 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] Allow comments after conditionals (PR #2996)
Ah, ok, so this works, but not for the `%endif`. I cannot say I grasped it from the documentation update :/ -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2996#issuecomment-2022749958 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] Allow comments after conditionals (PR #2996)
> > `%dnl` already works for this purpose, doesn't it?
>
> It doesn't, because this check happens before macro expansion.
This fails:
~~~
$ cat license-subpackages.spec
Summary: Demonstration package for mining licenses from subpackages
Name: license-subpackages
Version: 1
Release: 1%{?dist}
License: BSD-3-Clause AND MIT
%description
Using Lua and "metaprograming", it is possible to do magic with .spec files
such as collecting licenses from subpackages.
%if 0 # comment
%package foo
Summary: foo subpackage
License: BSD-3-Clause
%description foo
This foo subpackage
%files foo
%endif
%changelog
* Wed Mar 13 2024 Vít Ondruch
- Initial version
$ fedpkg --release f41 srpm
Failed to get repository name from Git url or pushurl
Failed to get ns from Git url or pushurl
error: parse error in expression: 0 # comment
error: ^
error: /home/vondruch/license-subpackages/license-subpackages.spec:12: bad %if
condition: 0 # comment
error: query of specfile
/home/vondruch/license-subpackages/license-subpackages.spec failed, can't parse
Could not execute srpm: Could not get n-v-r-e from
/home/vondruch/license-subpackages/license-subpackages.spec
$ rpm -q rpm
rpm-4.19.1.1-1.fc40.x86_64
~~~
While this passes:
~~~
$ diff -u license-subpackages.spec{.orig,}
--- license-subpackages.spec.orig 2024-03-27 14:05:58.511376998 +0100
+++ license-subpackages.spec2024-03-27 14:06:05.735409184 +0100
@@ -9,7 +9,7 @@
such as collecting licenses from subpackages.
-%if 0 # comment
+%if 0 %dnl # comment
%package foo
Summary: foo subpackage
License: BSD-3-Clause
~~~
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2996#issuecomment-2022727660
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] Allow comments after conditionals (PR #2996)
`%dnl` already works for this purpose, doesn't it? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2996#issuecomment-2022331640 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] Cumulative `License` field (Discussion #2892)
Just realized that one problem is that RPM knows nothing about the actual content of the `License` tag, therefore it would not be easy to "just merge them" into single field, if needed. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2892#discussioncomment-8925584 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] `define(name, body)` documentation does not align with implementation (Issue #2962)
For the context, I have stumbled upon this issue playing with #2969 and my initial idea was to assign the whole macro body including the new lines to some macro with some specifically crafted name. But I was not able to achieve that no matter what and resorted to use variables (which is probably good enough variant). It is my feeling that for whatever reason defining macro in Lua is limited comparing to plain .spec file, not being able to insert new line there. But maybe I have just not figured out the right amount of backslashes or what not. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2962#issuecomment-2010097636 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] Add support for bare `%package` (Discussion #2959)
I wish you could elaborate more. From your answer, I am not able to deduce 1. If you like / not like the idea if you were free from current implementation 2. What it would take to change the implementation 3. If there are any hopes or not -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2959#discussioncomment-8841037 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] rpmbuild should error out on conflicting %exclude directive (Issue #2952)
I have not really wanted to suggest this should be prohibited / reported as an error. But since duplicates are already detected and reported, reporting this would be in line with that and possibly prevented possible surprises, so that is acceptable. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2952#issuecomment-2004027197 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] %exclude is too strong (Issue #2952)
> the only reasonable course of action is erroring out. Shall I open separate ticket? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2952#issuecomment-2003741467 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] Meta programming in .spec using Lua, is it heresy? (Discussion #2969)
I am playing with ideas such as #2959 or #2892 and here is a proposal how to
achieve that (and much more). This could be the .spec file:
~~~rpm-spec
%define subpackage() %{lua:
subpackage = arg[1]
subpackage_name = subpackage:match("\\n%%package%s*([^\\n]*)")
if subpackages == nil then
subpackages = {}
end
subpackages[subpackage_name] = subpackage
if licenses == nil then
licenses = {}
end
licenses[subpackage_name] = subpackage:match("\\nLicense:%s*([^\\n]*)")
}
%define subpackages() %{lua:
for k in pairs(subpackages) do
print(rpm.expand(subpackages[k]))
end
}
%define licenses() %{lua:
local license = arg[1]
for k in pairs(licenses) do
l = licenses[k]
if l then
license = license .. " AND " .. l
end
end
print(license)
}
%{subpackage:
%package foo
Summary: foo subpackage
License: BSD
%description foo
This random subpackage
%files foo
}
Summary: Demonstration package for mining licenses from subpackages
Name: license-subpackages
Version: 1
Release: 1%{?dist}
License: %{licenses:MIT}
%description
Using Lua and "metaprograming", it is possible to do magic with .spec files
such as collecting licenses from subpackages.
%{subpackages}
%changelog
* Wed Mar 13 2024 Vít Ondruch
- Initial version
~~~
The SRPM would look like this:
~~~
$ rpm -qp --qf "%{SPEC}" license-subpackages-1-1.fc41.src.rpm
Summary: Demonstration package for mining licenses from subpackages
Name: license-subpackages
Version: 1
Release: 1.fc41
License: MIT AND BSD
%description
Using Lua and "metaprograming", it is possible to do magic with .spec files
such as collecting licenses from subpackages.
%package foo
Summary: foo subpackage
License: BSD
%description foo
This random subpackage
%files foo
%changelog
* Wed Mar 13 2024 Vít Ondruch
- Initial version
~~~
I can imagine quite a lot more done with something similar. This trick could be
used to enable/disable subpackages at will. If there were requires/provides,
they could be adjusted for systems such as SCL. Is there some functionality or
tag which RPM does not support (yet?), no problem to implement it in such macro.
Is this going too far?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2969
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] Lua equivalent to `%{echo:...}` and similar (Discussion #2968)
Yes, I don't argue with that. But output from Lua to terminal is useful and would IMHO deserve some separate note. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2968#discussioncomment-8772227 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] Lua equivalent to `%{echo:...}` and similar (Issue #2967)
TBH figuring out `rpm.expand("%{echo: some output}")` is also not that straight
forward. I was able to find such example at least.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2967#issuecomment-1994195978
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] Lua equivalent to `%{echo:...}` and similar (Issue #2967)
Oh. Interesting, the for the tip Nevertheless, I was not able to figure that out myself, therefore it would deserve to be documented if that is the right approach. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2967#issuecomment-1994192617 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] Lua equivalent to `%{echo:...}` and similar (Issue #2967)
Currently the way to get some information from Lua macro is quite clumsy. One
needs to do something like:
~~~
%define foo() %{lua:
rpm.expand("%{echo: some output}")
}
~~~
Would it be possible to make it easier, e.g. something like this would be more
convenient:
~~~
%define foo() %{lua:
rpm.echo("some output")
}
~~~
Or maybe just:
~~~
%define foo() %{lua:
echo("some output")
}
~~~
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2967
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] `define(name, body)` documentation is incorrect (Issue #2962)
IOW this is what the heading says:
~~~
$ rpm -E "%{lua:rpm.define('foo', '1')}" -E "%foo"
error: Macro %foo has empty body
error: lua script failed: [string ""]:1: error defining macro
~~~
but this is how it actually works:
~~~
$ rpm -E "%{lua:rpm.define('foo 1')}" -E "%foo"
1
~~~
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2962#issuecomment-1991262402
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] `define(name, body)` documentation is incorrect (Issue #2962)
This line is incorrect IMHO: https://github.com/rpm-software-management/rpm/blob/689f1d8d3ef4fcba4b4d05160cb5063b8ac11310/docs/manual/lua.md?plain=1#L120 It should actually be something like `define(name_body)`. This example actually seems to be correct: https://github.com/rpm-software-management/rpm/blob/689f1d8d3ef4fcba4b4d05160cb5063b8ac11310/docs/manual/lua.md?plain=1#L128 But in any case, it would make more sense if the header was correct. Why it does not work like this? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2962 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] Add support for bare `%package` (Discussion #2959)
Could there be added support for bare `%package`, without any argument or
option? Several reasons I can think of.
1) Having plain `%description` / `%files` without its `%package` counterpart is
asymmetric
2) Having bare `%package` somewhere in the .spec file could allow to use the
original preamble (if present) just in SRPM context.
3) Having bare `%package` would allow to place the main package declaration
freely in .spec file.
The third point is actually my original motivation related to #2892. I believe
that if I replaced the `License:` tags by some macro, I could likely accumulate
the licenses and use them in the `%package` which would be listed as last. This
in turn would likely allowed me to conditionalize the sub-package existence.
IOW the most naive (and incomplete) example could look like this:
~~~rpm-spec
%package libs
Summary: foo-libs
%description libs
foo-libs description
%package
Summary: foo
Name: foo
Version: 1
Release: 1%{?dist}
License: MIT
%description
foo description
%files
%files libs
%changelog
~~~
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2959
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] Indentation support for tags (Issue #2927)
Just FTR, I keep asking because example like this: https://src.fedoraproject.org/rpms/nodejs20/blob/3391b85e233fb582fff9471c23788df5ad582d21/f/nodejs20.spec#_156-162 What could be nested here if the PR was accepted? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2927#issuecomment-1988728668 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] Indentation support for tags (Issue #2927)
> The situation wrt other sections is a bit more complicated. RPM itself does > not really support indentation in most. Instead for most sections (scripts > and scriptlets) it just does macro expansion and `#if` magic and then hands > the result to some interpreter - or sticks it into a tag to be handed to an > interpreter later. So basically each section has it's own syntax. E.g. > `%sources` and `%patches` will happily add any indentation to the front of > the file name. So we are talking about the Preamble here only. Yes, section content is section content. But I think that this is not possible: ` %description` (note the space before `%`): ~~~ error: line 101: Unknown tag: %description ~~~ and I might be wrong, but I don't see this supported by the PR. Or at least I can't see this covered by test case. Also I am not sure how the ` %package foo` would work. RPM does not report any error ATM and I suspect that such line is assumed to be part of earlier `%description` in my case, because adding `%description foo` afterwards, I receive error: ~~~ error: line 106: %description foo: package newpackage-foo does not exist ~~~ -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2927#issuecomment-1988711676 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] Indentation support for tags (Issue #2927)
If the nesting for preamble was allowed, would be nestable also other sections, such as `%describtion`, `%pre`, etc? BTW this change would break at minimum Vim syntax highlighter. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2927#issuecomment-1988628252 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] Indentation support for tags (Issue #2927)
> Not sure why your personal taste would have any weight in this discussion
Maybe because you value community feedback?
> Neither does this change require proper nesting from anyone
Actually RPM requires proper nesting now (no nesting) and it is mostly fine.
Allowing nesting will open the discussion about proper nesting, if it should be
e.g. 2 spaces or single tab etc. It will motivate people to adjust nesting by
conditions, making diffs bigger.
No choice is sometimes better.
> nor is white space disallowed in these macro expressions (as one can easily
> check with `rpm -E`).
Not everything can be tested by `rpm -E` probably:
~~~
$ rpmbuild -D "_sourceddir ." -D "_srpmdir ." -bs newpackage.spec
setting SOURCE_DATE_EPOCH=1705363200
Wrote: /home/vondruch/rpmbuild/SRPMS/newpackage-1-1.fc41.src.rpm
~~~
vs:
~~~
$ rpmbuild -D "_sourceddir ." -D "_srpmdir ." -bs newpackage.spec.space
error: line 150: Unknown tag: BuildRequires: foo
~~~
and this is the difference:
~~~
$ diff -u newpackage.spec{,.space}
--- newpackage.spec 2024-03-11 14:59:41.476458832 +0100
+++ newpackage.spec.space 2024-03-11 14:59:37.510442485 +0100
@@ -147,7 +147,7 @@
Version: 1
Release: 1%{?dist}
License: MIT
-%{!?foo:BuildRequires: foo}
+%{!?foo: BuildRequires: foo}
%description
~~~
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2927#issuecomment-1988523363
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] Indentation support for tags (Issue #2927)
I am against this request. The .spec file is not exactly easy to parse and this
won't improve the situation. Also, it is kind of relieving that I don't have to
bother with "proper" nesting inside conditionals.
BTW what is the impact on the shorthand such as:
~~~
{?suse_version:Requires: xdotool}
{!?suse_version:Requires: libxdo}
~~~
I think the space is currently not allowed in this construct
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2927#issuecomment-1988213113
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] %exclude is too strong (Issue #2952)
Given this .spec file:
~~~rpm-spec
Summary: summary
Name: newpackage
Version: 1
Release: 1%{?dist}
License: MIT
%description
%install
mkdir -p %{buildroot}%{_tmppath}
echo "foo" > %{buildroot}%{_tmppath}/f
%files
%exclude %{_tmppath}/f
%{_tmppath}/f
%changelog
* Tue Jan 16 2024 Vít Ondruch
- newpackage
~~~
where the file is excluded first and included later, I'd expect that the file
will be included in the package, but that is not the case:
~~~
$ rpm -qpl
/var/lib/mock/fedora-rawhide-x86_64/result/newpackage-1-1.fc40.x86_64.rpm
(contains no files)
~~~
Please note that I have faced the issue when I was trying to remove some
subpackages, but keep the files section as similar to the original state as
possible.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2952
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] How to obsolete package once their dependencies are not satisfied? (Discussion #2938)
We agree that at some point, it is good idea to forcefully remove some package from a system. We know how to remove the package from the system, when it is removed from repository using e.g. [fedora-obsolete-packages](https://src.fedoraproject.org/rpms/fedora-obsolete-packages). The method could certainly be improved, but it works. But the [assertion was](https://src.fedoraproject.org/rpms/fedora-obsolete-packages/pull-request/86#comment-186335): _"So since Fedora wants to preserve installed packages on system upgrade, even if they are not available in the new release, straight obsoleting is not the correct action. And if a package needs to be obsoleted is not necessarily known at orphaning or retirement time."_ I see two options to help with this situation. 1) Improve metadata in RPM, because we can predict that if package not being maintained anymore, depending e.g. on `libruby.so.3.2()(64bit)` should be removed as soon and such provide is not available. 2) Improve process to collect appropriate metadata in fedora-obsolete-packages. Currently the process is "Lets ask users on ML for upgrade problems". We could possibly do better. In any case, the purpose of this discussion is to focus on (1), i.e. is there something what RPM could do to help remove broken packages at the right moment? Because it is simply not surprise that e.g. `libruby.so.3.2()(64bit)` won't be available one day. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2938#discussioncomment-8690792 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] How to obsolete package once their dependencies are not satisfied? (Discussion #2938)
Well, maybe. But that would be certainly task for DNF. Although I still believe that some people prefer to keep the removed packages around as long as possible. Maybe even longer, but then they could possible exclude those from transaction. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2938#discussioncomment-8682165 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] How to obsolete package once their dependencies are not satisfied? (Discussion #2938)
What the fedora-obsolete-packages can do is to remove such package immediately. But that is not strictly needed. It is needed only when the ABI is broken. I would like to have something like: `Obsoletes: rubygem-byebug unless libruby.so.3.2()(64bit)` or: `Obsoletes: rubygem-byebug if its-dependencies-can't-be-satisfied-anymore` Something like "soft obsolete", which would keep the package around as long as it is not objectively broken, no matter what is in repository (because repository is not the thing for RPM). -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2938#discussioncomment-8682031 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] How to obsolete package once their dependencies are not satisfied? (Discussion #2938)
Yes, the package is precondition. But the question is if the `Obsolete` can be more nuanced. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2938#discussioncomment-8681216 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] How to obsolete package once their dependencies are not satisfied? (Discussion #2938)
Lets have some package installed on a system, which is already removed from the repository. This package might work just fine as long as their dependencies are satisfied. But after the dependencies change, the package needs to be removed. Is there a way to obsolete package under such condition? The specific example could be this: ~~~ Problem 3: package rubygem-byebug-11.1.3-5.fc39.x86_64 from @System requires libruby.so.3.2()(64bit), but none of the providers can be installed - ruby-libs-3.2.2-181.fc39.x86_64 from @System does not belong to a distupgrade repository - problem with installed package rubygem-byebug-11.1.3-5.fc39.x86_64 ~~~ As long as the `libruby.so.3.2()(64bit)` is available, the rubygem-byebug-11.1.3-5.fc39.x86_64 package works fine. But is there a way to remove it from a system once the `libruby.so.3.2()(64bit)` is not available anymore? [This](https://src.fedoraproject.org/rpms/fedora-obsolete-packages/pull-request/86#) ticket is the background for my question. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2938 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] Introduction of "rpms.lock.yaml" file (Discussion #2908)
RPM knows that from command line parameter. Obviously `rpm -I vim-enhanced-10.0.038-1.fc38.x86_64.rpm` will look for the package in current directory. IOW the information where to get the package to install is always external to RPM. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2908#discussioncomment-8559235 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] Please backport support for spec local file attributes and generators into stable RPM (Issue #2918)
I wonder if you would be open to backport the support for [spec local file attributes and generators](https://github.com/rpm-software-management/rpm/pull/2911) into stable RPM. This would allow us to drop the rpm-local-generator-support package from Fedora and migrate the current downstream users to the `_local_file_attrs` instead. I have already asked [backport in Fedora](https://bugzilla.redhat.com/show_bug.cgi?id=2264885), but I was redirected here. And to be fully transparent, I am asking the backport here and now, because it would actually allow us to drop the rpm-local-generator-support package from Fedora and hopefully also from RHEL10. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2918 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] Introduction of "rpms.lock.yaml" file (Discussion #2908)
Fedora also used Mirror Manager, therefore the explicit URLs (in the original example) are going against that. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2908#discussioncomment-8528588 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] Introduction of "rpms.lock.yaml" file (Discussion #2908)
Right, RPM does not have any concept of repos. As it mostly does not care about URLs and generally does not care about where the RPM comes from. But let me explain what I mean. This lock file (based on your initial example, and sorry if I don't have the YAML syntax right) in the simplest form could be interesting for RPM IMHO: ~~~yaml lockfileVersion: 1 packages: - vim-enhanced-9.1.031-1.fc38.x86_64.rpm - vim-common-9.1.031-1.fc38.x86_64.rpm - vim-filesystem-9.1.031-1.fc38.noarch.rpm - gpm-libs-1.20.7-42.fc38.x86_64.rpm - ... ~~~ If I did `rpm -I vim-enhanced-10.0.038-1.fc38.x86_64.rpm`, the command would fail, because the NVR does not match the lock file. If I did `rpm -I foo`, this wold also fail, because `foo` package is not listed in the lock file. But doing `rpm -I vim-enhanced-9.1.031-1.fc38.x86_64.rpm` would work. On top of that, if the command would be `rpm -I https://mirrors.nic.cz/pub/fedora/linux/updates/38/Everything/x86_64/Packages/v/vim-enhanced-9.1.031-1.fc38.x86_64.rpm` RPM could also check the URL if it was part of the lock file as in your initial proposal. IOW this would allow version pinning which could probably be useful RPM feature. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2908#discussioncomment-8527930 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] Introduction of "rpms.lock.yaml" file (Discussion #2908)
RPM checks dependencies, doesn't it? Then I don't see why RPM should not allow only the dependencies as specified in some lock file, maybe ignoring the full URL just focusing on NVR -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2908#discussioncomment-8526953 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] Arguments are not propagate into global lua macro (Issue #2910)
**Describe the bug**
It seems that global lua macro does not have correctly populated arguments.
**To Reproduce**
This seems to work as expected:
~~~
$ cat newpackage.spec | head -11
%define foo(a:b) %{lua:
if #arg == 0 then
print('no arguments :(')
else
for i = 1, #arg do
print(arg[i])
end
end
}
%{foo bar}
$ rpmbuild -D "_sourceddir ." -D "_srpmdir ." -bs newpackage.spec
error: line 11: Unknown tag: bar
~~~
IOW it outputs `bar` into the .spec file and therefore the rpmbuild fails. So
far so good. However:
~~~
$ sed -i "/foo(/ s/define/global/" newpackage.spec
$ cat newpackage.spec | head -11
%global foo(a:b) %{lua:
if #arg == 0 then
print('no arguments :(')
else
for i = 1, #arg do
print(arg[i])
end
end
}
%{foo bar}
$ rpmbuild -D "_sourceddir ." -D "_srpmdir ." -bs newpackage.spec
error: line 11: Unknown tag: no arguments :(
~~~
IOW this evals the `#arg` to zero and prints the `no arguments :(` message from
the associated branch.
**Expected behavior**
The `%global` version should either:
1. Behave the same as `%define` and correctly process arguments.
or
2. Should refuse such use.
**Environment**
- OS / Distribution: Fedora Rawhide
- Version: rpm-4.19.1-4.fc40.x86_64
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2910
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] Cumulative `License` field (Discussion #2892)
Apart from the example above, which could make easier to elaborate about the licenses, I have package with subpackages which I am trying to drop (include in the main package). However, each of this subpackages has its own license field. If the license was cumulative, I could just copy paste the subpackage licensing section as it is. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2892#discussioncomment-8407529 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] Can `License` field work cumulatively (Discussion #2892)
Specifying multiple `License` fields is currently prohibited:
~~~
warning: line 180: second License
error: Duplicate License entries in package: (main package)
~~~
Is it possible to change the behavior so the multiple license fields were
supported and there would be `AND` relation between them?
For example, currently the license line can look like this:
~~~
# BSD-3-Clause: missing/{crypt,mt19937,setproctitle}.c
# ISC: missing/strl{cat,cpy}.c
# Public Domain for example for: include/ruby/st.h, strftime.c, missing/*, ...
# MIT and CCO: ccan/*
# zlib: ext/digest/md5/md5.*, ext/nkf/nkf-utf8/nkf.c
# Unicode-DFS-2015: some of enc/trans/**/*.src
License: (Ruby OR BSD-2-Clause) AND BSD-3-Clause AND ISC AND Public Domain AND
MIT and CC0 AND zlib AND Unicode-DFS-2015
~~~
But it could look this way:
~~~
License: Ruby OR BSD-2-Clause
# BSD-3-Clause: missing/{crypt,mt19937,setproctitle}.c
License: BSD-3-Clause
# ISC: missing/strl{cat,cpy}.c
License: ISC
# Public Domain for example for: include/ruby/st.h, strftime.c, missing/*, ..
License: Public Domain
# MIT and CCO: ccan/*
License: MIT and CC0
# zlib: ext/digest/md5/md5.*, ext/nkf/nkf-utf8/nkf.c
License: zlib
# Unicode-DFS-2015: some of enc/trans/**/*.src
License: Unicode-DFS-2015
~~~
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2892
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)
> > Not a fan of the `-PKG` and `-root` suffixes. > > If you just have 'foo-1.0/foo-1.0/' its easy to mix up etc. I don't mind this path. But if the path actually was 'foo-1.0/SOURCE/' that could mitigate your concern. And yes, there is #2859 always expanding the tarball into name-version directory, so if the expansion was instead always into `SRC` that would not be so bad IMHO. But arguably, quite some projects place their real sources into something like `src` directory, so then there could be patch like 'foo-1.0/SOURCE/src' -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2885#issuecomment-1931607769 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)
> And, -s points at the source directory when it's the build directory you'd
> like to be able to name, so it's quite backwards.
Oh, now I see. The patch actually works the opposite way then I anticipated. It
actually introduces `%{sourcesubdir}` while the `%{buildsubdir}` is actually
already existing and is the current directory for `%configure` but also `%make`
call, as it always was. This also explains the quote bellow, why you don't see
need to change the make macros.
> > 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`
>
> There's nothing to update wrt the make macros. configure, which exists in the
> _soure_ directory, generates the makefiles into the build directory, and then
> you just run make as you always did. Noisiness has nothing to do with it.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2886#issuecomment-1929658172
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] Add "local_generator" (PR #2734)
@voxik commented on this pull request. > @@ -995,6 +995,25 @@ runroot rpm -qp --requires > /build/RPMS/noarch/shebang-0.1-1.noarch.rpm|grep -v ^ []) RPMTEST_CLEANUP +AT_SETUP([Local dependency generator]) +AT_KEYWORDS([build]) +RPMTEST_CHECK([ +RPMDB_INIT + +runroot rpmbuild -bb --quiet \ + --define '__local_file_attrs my_test_attr' \ If this covered multiple generators to demonstrate that something like this is supported, that would be even better -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2734#pullrequestreview-1865093933 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)
> I guess what you mean by "merging" is something entirely different than me & > ffesti think of. In my naive view, I see binary RPM as nothing more then (fancy) tarballs. And combining two tarballs is legitimate operation AFAIK, given there is `tar --concatenate` option. > Binary rpm's are immutable end products of a spec which directs rpmbuild to > produce said rpms. Somehow undoing a separation set by the packager is just > not a meaningful operation at all. The only meaningful merge in rpm land is > something a packager does, at a spec/srpm level. I see it differently. If you abstract away, then several merged RPMs gives you e.g. container image (Yes, I have deliberately removed a lot of complexities). -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2887#discussioncomment-8381793 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)
> These details are nowhere near fully thought through, and are certainly > debatable and open/subject to change. In my initial patch buildroot was > always BUILDROOT, but then experimenting with the vpath build stuff and your > own mention about potentially needing multiple build directories made me > think perhaps it should match the build directory name, and those are > commonly named by the target tuple. While I think multiple directories for vpath builds are useful, if `BUILDROOT` is still the image of what will be installed on the resulting system, then my current thinking is that there should be only one destination, where everything should be parallel installable if possible. But maybe you had the `curl` example with `RemovePathPostfixes` on your mind which could be legitimate reason. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2885#issuecomment-1929343652 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)
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] 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
[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] 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
Re: [Rpm-maint] [rpm-software-management/rpm] Native support for separate build and source tree (aka vpath builds) (Discussion #2882)
Fedora already has [`%{_vpath_builddir}`
macro](https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/rawhide/f/macros.vpath)
for such purpose. And
[this](https://src.fedoraproject.org/rpms/ruby/c/cbe746e311d5dbfd9c6d42fdfc4147220c0ad791)
is how I migrated Ruby to out-of-source build using this macro.
However, there is also need for more then one build dir. AFAIK
[Python](https://src.fedoraproject.org/rpms/python3.12/blob/rawhide/f/python3.12.spec)
does two builds, one optimized and second with debug information.
[Vim](https://src.fedoraproject.org/rpms/vim/blob/rawhide/f/vim.spec) does 3
different builds (and it would be probably better to use separate build dirs
for them).
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2882#discussioncomment-8346269
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)
At this stage, I don't want to really constrain myself by `Source` being attached to subpackage or not. But if there is space for [append / prepend scriptlets](https://github.com/rpm-software-management/rpm/pull/2728), then I don't see the package specific scriptlets to being way off. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2849#discussioncomment-8318968 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] Add "local_generator" (PR #2734)
`__embedded_file_attrs`? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2734#issuecomment-1918940894 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 available a macro with package name during processing `%files` section? (Discussion #2876)
Please see the last several files section of [ruby.spec](https://src.fedoraproject.org/rpms/ruby/blob/rawhide/f/ruby.spec#_1563-1649). Granted, there is a lot of similarities between the `%files` sections, but they are not the same. On top of that, some of them are also similar to the dual life packages, e.g. [rubygem-minitest](https://src.fedoraproject.org/rpms/rubygem-minitest/blob/rawhide/f/rubygem-minitest.spec). It would be neat if the dual life packages could have the same `%files` sections. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2876#discussioncomment-8248329 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 available a macro with package name during processing `%files` section? (Discussion #2876)
But maybe the `%files` section should be obsolete and replaced by file lists ... -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2876#discussioncomment-8245318 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 available a macro with package name during processing `%files` section? (Discussion #2876)
I think my example was not clear enough. Lets concentrate on the later part:
~~~
%gem_extdir_mri psych}
%dir %{gem_instdir psych}
%{gem_libdir psych}
%{gem_spec -d psych}
~~~
If there was some macro with package name, I think I could simplify this:
~~~
%{gem_extdir_mri}
%dir %{gem_instdir}
%{gem_libdir}
%{gem_spec -d}
~~~
I'd probably left the part at the beginning untouched.
But still, seeing where you go and admitting it has some merit, I'd probably go
without the cycle:
~~~
n=psych
cat << EOF > ${n}.txt
%{ruby_libdir}/${n}
%{ruby_libdir}/${n}.rb
%{ruby_libarchdir}/${n}.so
#...
EOF
n=mental
cat << EOF > ${n}.txt
%{ruby_libdir}/${n}
%{ruby_libdir}/${n}.rb
#...
EOF
~~~
Maybe because the `mental` does not have the .so file.
But then having the `%files` section feels useless. I think there was similar
discussion about the `%excludes`.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2876#discussioncomment-8245305
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 available a macro with package name during processing `%files` section? (Discussion #2876)
> If you have lots of those with nothing but the name changing, no macros will
> help with that.
Since e.g. the `gem_libdir` is macro, it could instead of accepting the
parameter use some macro on background. So the question is can we have such
macro?
> Generate those files manifests programmatically from %install and include
> with %files -f. Or use dynamic spec generation to generate even those.
For me, the `%files` section is not about getting some random files into
package. If I greatly simplify the problem, the files section such as:
~~~
%files
%{_libdir}
~~~
is not the way to go and generated file list are very similar to this. While
they allow to include everything what is on file system, they don't cover my
back and they don't tell mi if e.g. soname has changed, if there are new files,
which need review or if some files gone missing.
But maybe I just like doing things the hard way 路
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2876#discussioncomment-8244926
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 available a macro with package name during processing `%files` section? (Discussion #2876)
In `ruby` package, there are sections such as:
~~~
%files -n rubygem-psych
%{ruby_libdir}/psych
%{ruby_libdir}/psych.rb
%{ruby_libarchdir}/psych.so
%gem_extdir_mri psych}
%dir %{gem_instdir psych}
%{gem_libdir psych}
%{gem_spec -d psych}
~~~
And as it can be seen, the `psych` argument is there pretty repetitive. So I
wonder, is there by a chance macro, which would contain name of the `%files`
section which is actually processed?
Yes, there is the `rubygem-` prefix, but ...
Or maybe I could set some `files_name` variable on top of each `%files` section?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2876
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] Add "local_generator" (PR #2734)
`__override_file_attrs`, which would give higher prominence to the regular installed attrs and discouraged use of this feature. But that brings me back to the `__extra_file_attrs`, which I have read after I was thinking about `__override_file_attrs` ;) IOW `__extra_file_attrs` sounds good to me. `__additional_file_attrs` could also be option. It sounds mundane, but maybe that makes it the better choice. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2734#issuecomment-1905700754 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] Add "local_generator" (PR #2734)
`packaged` or `package`? I am asking, because the generators are not packaged yet as I perceive that. But I can live also with `packaged` :) -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2734#issuecomment-1904388907 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] Add "local_generator" (PR #2734)
@voxik commented on this pull request. > @@ -132,6 +132,14 @@ Enabling the multifile mode is done by setting %__foo_protocol multifile ``` +## Using File Attributes in their own Package + +Normally file attributes and their dependency generators are shipped in separate packages that need to be installed before the package making use of them can be build. + +Since rpm 4.20 the names of file attribute shipped with the package can be put into the *__packaged_file_attrs* macro separated by colons (:). The macros that normally go into the *\*.attr* files still need to be defined (the dependency generators typically pointing to some Source files or some files in the install root). + I think that example would be useful here. Also the following paragraph is not very tangible without example. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2734#pullrequestreview-1836891196 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] Add "local_generator" (PR #2734)
> I think the issues is reproducibility and correctness. If you fix the
> dependency generator in your package you don't want to old - possibly broken
> - deps still in your package, just because the old package is still on your
> build system.
That is actually good point.
So in the Ruby case, it would actually make sense to override the `rubygems`
macros, which would make sure the generator shipped with Ruby is the only one
used. IOW there would need to be:
~~~
%global __local_file_attrs rubygems
%global __rubygems_requires make -C
%{_builddir}/%{buildsubdir}/%{_vpath_builddir} -s runruby
TESTRUN_SCRIPT="--enable-gems %{SOURCE9}"
%global __rubygems_provides make -C
%{_builddir}/%{buildsubdir}/%{_vpath_builddir} -s runruby
TESTRUN_SCRIPT="--enable-gems %{SOURCE10}"
%global __rubygems_conflicts make -C
%{_builddir}/%{buildsubdir}/%{_vpath_builddir} -s runruby
TESTRUN_SCRIPT="--enable-gems %{SOURCE11}"
%global __rubygems_path ^%{gem_dir}/specifications/.*\.gemspec$
~~~
Actually, this leads me to another silly idea. Maybe the `rubygems.attr` could
be loaded instead of the overrides if it was crafted properly ...
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2734#issuecomment-1898330857
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] Add "local_generator" (PR #2734)
> I am thinking about actually shipping the dependency generator but also using > it in the package itself. This ^^ actually is my use case and here is how it looks in practice: https://src.fedoraproject.org/rpms/ruby/blob/308b2c0ab2c6268847ed3bf2008e74bce334e810/f/ruby.spec#_187-190 https://src.fedoraproject.org/rpms/ruby/blob/308b2c0ab2c6268847ed3bf2008e74bce334e810/f/ruby.spec#_203-206 https://src.fedoraproject.org/rpms/ruby/blob/308b2c0ab2c6268847ed3bf2008e74bce334e810/f/ruby.spec#_795-800 https://src.fedoraproject.org/rpms/ruby/blob/308b2c0ab2c6268847ed3bf2008e74bce334e810/f/ruby.spec#_1330-1335 Saying all these, it makes me realize that in theory, if the `rubygems-devel` package was installed during Ruby build, the generators could actually run twice. But they are executed for specific path based on specific macro: https://src.fedoraproject.org/rpms/ruby/blob/308b2c0ab2c6268847ed3bf2008e74bce334e810/f/rubygems.attr#_6 Not sure. In reality, having Ruby installed during build of Ruby is problematic for different reasons, so I don't have to be worried in this case. > For that you need to make sure that it is only run once during the build - > even if the package is actually installed in the system building the package. Do I? I don't think there is currently anything, which would prevent one generator running twice. E.g. if there are multiple `.attr` files pointing to the same script. Also the macros can be changed any time to point to the same script. And the generators can also be disabled by changing the macro. Actually, from this POV, my original PR making the `local_generator` special kind of helps to mitigate the concerns. The more flexibility will provide more opportunities for clashes. Nevertheless, let me be clear that I am not really arguing for or against of any of those variant. Both versions are acceptable. But it is good to understand all the corner cases -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2734#issuecomment-1898123753 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] Add "local_generator" (PR #2734)
On the second thought, maybe it really is the right way. I am coming from place where no "local" generator us was possible, so one was already great improvement. But maybe there are use cases for multiple generators? OTOH, one could call them via some helper script or by chaining them (in the worst case by executing `bash` or what not). -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2734#issuecomment-1898067418 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] Add "local_generator" (PR #2734)
@voxik commented on this pull request. > @@ -866,6 +866,7 @@ RPMTEST_CHECK([ RPMDB_INIT runroot rpmbuild -bb --quiet \ + --define '__local_file_attrs local_generator' \ Maybe something like `totally_random_generator_name` -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2734#discussion_r1457125066 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] Add "local_generator" (PR #2734)
> OK, just hard coding one file attribute doesn't seem like a good idea. I > added a macro that allows you to register an arbitrary number of local file > attributes and generators. Nice, now we can argue if the `__local_file_attrs` is the right name or rather e.g. `__package_local_file_attrs` 藍 Sorry, couldn't resist. Nevertheless, thx for contributing. I see your point. OTOH, if I read your commit correctly, my original proposal had the advantage, where one could count with convention over configuration. IOW with your changes one additional line is needed to make this work. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2734#issuecomment-1898047160 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] Add "local_generator" (PR #2734)
@voxik commented on this pull request. > @@ -866,6 +866,7 @@ RPMTEST_CHECK([ RPMDB_INIT runroot rpmbuild -bb --quiet \ + --define '__local_file_attrs local_generator' \ While this is "just test case", maybe the `local_generator` could use different name, just to avoid the impression that the `local` is somehow mandatory in the latter -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2734#pullrequestreview-1829143312 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] Package specific prep/build/... sections (Discussion #2849)
AFACIT, the sub-package may include `Source` directive. But is there a chance to have also named prep/build/... sections? BTW wonder what happens with the string appended behind e.g. `prep`. Can I really put there any garbage I like, such as `%prep asl;dkfjsld;fkj`? But I assume this is likely going to change with #2728 -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2849 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] Provide better support for versioned RPMs (Discussion #2847)
BTW looking around, `%source_name` used e.g. [here](https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/rawhide/f/macros.fedora-misc-srpm) might be interesting concept and that is what I was aiming at in the last paragraph. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2847#discussioncomment-8145995 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] Provide better support for versioned RPMs (Discussion #2847)
It is pretty common to provide versioned RPMs. E.g. in Fedora, there are
[nodejs20](https://src.fedoraproject.org/rpms/nodejs20/blob/rawhide/f/nodejs20.spec),
[nodejs18](https://src.fedoraproject.org/rpms/nodejs18/blob/rawhide/f/nodejs18.spec),
[python3.x](https://src.fedoraproject.org/rpms/python3.9/blob/rawhide/f/python3.9.spec)
packages, there were added versioned
[postgresql16](https://src.fedoraproject.org/rpms/postgresql16/blob/rawhide/f/postgresql16.spec)
packages recently, etc. And I wonder if RPM could provide some basic support
to help with this scenario.
The most common issue is that typically, there is need for two "package names",
the original non versioned as well as versioned, e.g. `%{name}` and
`%{pkg_name}`. The versioned name is typically constructed from some other
major/minor/teeny version macros used as an suffix or prefix (in case of SCL).
However, which macro contains what value varies. And that is due to sub-package
naming.
The standard way is that the package declares just the suffix to the main
package name. However, for the versioned rpms, it depends if the main package
name is versioned or not, this means that the suffixes work just fine or all
package names needs to be fully named.
So I think that in short, what I am looking for is a way to have the versioned
name and a switch, which would tell RPM to use the versioned name for the
sub-packages.
BTW I think that what is also interesting with the versioned packages is that
the "main package" might not be shipped. That is for example case of the
nodejs20 package in Fedora, where the main binary package is named nodejs.
Therefore I wonder, is there a change to make the "main package" less
significant? Maybe it should be declared by `%package` declaration and treated
similarly to other sub-packages.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2847
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] Create Issue templates for Bug reports and RFEs (PR #2823)
@voxik commented on this pull request. > @@ -0,0 +1,22 @@ +--- +name: Feature request +about: Suggest an idea for this project +title: '' +labels: RFE +assignees: '' + +--- + +If your feature need figuring out how to implement it or needs feedback from the wider comunity, please open a [Discussion](https://github.com/rpm-software-management/rpm/discussions) instead. If the discussion has solidified into a plan of action it is time to create an issue for actually implementing it. > Oh, we have a confirmed rpm-maint reader. I've suspected nobody looks at that > anymore because volume and format... At least my rumbling was good for something :see_no_evil: Yes, rpm-maint is the most consumable format allowing to follow what is going on with RPM. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2823#discussion_r1445992798 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] Create Issue templates for Bug reports and RFEs (PR #2823)
@voxik commented on this pull request. > @@ -0,0 +1,22 @@ +--- +name: Feature request +about: Suggest an idea for this project +title: '' +labels: RFE +assignees: '' + +--- + +If your feature need figuring out how to implement it or needs feedback from the wider comunity, please open a [Discussion](https://github.com/rpm-software-management/rpm/discussions) instead. If the discussion has solidified into a plan of action it is time to create an issue for actually implementing it. > Just FTR, I dislike the discussions, mainly because I read everything through > rpm-maint ML and the discussions are not forwarded there AFAICT. Hm, checking the archives, I was wrong. I might change my mind, sorry for the nose. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2823#discussion_r1445986728 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] Create Issue templates for Bug reports and RFEs (PR #2823)
@voxik commented on this pull request. > @@ -0,0 +1,22 @@ +--- +name: Feature request +about: Suggest an idea for this project +title: '' +labels: RFE +assignees: '' + +--- + +If your feature need figuring out how to implement it or needs feedback from the wider comunity, please open a [Discussion](https://github.com/rpm-software-management/rpm/discussions) instead. If the discussion has solidified into a plan of action it is time to create an issue for actually implementing it. Just FTR, I dislike the discussions, mainly because I read everything through rpm-maint ML and the discussions are not forwarded there AFAICT. And I don't know if there is any meaningful way to subscribe to discussions, but I don't see any on the first look. IOW they might look like the best tool for the team or project members, but IMHO, they prevent collaboration in wider community. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2823#discussion_r1445974565 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 determine if a package is provided by OS repos or custom built? (Discussion #2808)
> Thanks for the repsonse. This doesn't work in Fedora-39. > > ``` > $ > ➜ $ dnf info rpm --disablerepo=* | grep repository > $ > ``` I was testing on Rawhide with DNF5. With DNF4, the output might be a bit different, but I believe that `dnf info rpm` still works. > > > I'd say this is out of scope for RPM > > Why do you believe so? It should be possible to have some kind of metadata to > indicate that the rpm is provided by OS. Not a mandatory field but on the > need basis. Because RPM does not have concept of something like OS in your view. RPM does not even have a concept of e.g. repository, which IMHO is narrower concept then OS -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2808#discussioncomment-7831297 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 determine if a package is provided by OS repos or custom built? (Discussion #2808)
I'd say this is out of scope for RPM, but e.g. DNF can have the answer: ~~~ # dnf info rpm | grep repository >From repository : rawhide ~~~ -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2808#discussioncomment-7829645 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] Declarative buildsystem, take II (PR #2774)
@voxik commented on this pull request. > @@ -1352,5 +1352,16 @@ end end } +# buildsystem defaults +%buildsystem_default_prep() %autosetup -p1 + +# example buildsystem macros for autotools I just wanted to open the question, because I am maintaining mainly rubygem-* packages where autotools are not used and RPM itself moved from autotools to cmake. Juste bing devils advocate, nothing more :smiling_imp: -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2774#discussion_r1401660513 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] Declarative buildsystem, take II (PR #2774)
> And in relation to #782, is it possible to define the 'buildsystem' inside of > the .spec file? Although admittedly, not sure what would be the utility 樂 -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2774#issuecomment-1821076512 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] Declarative buildsystem, take II (PR #2774)
And in relation to #782, is it possible to define the 'buildsystem' inside of the .spec file? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2774#issuecomment-1821074359 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] Declarative buildsystem, take II (PR #2774)
@voxik commented on this pull request. > @@ -1352,5 +1352,16 @@ end end } +# buildsystem defaults +%buildsystem_default_prep() %autosetup -p1 + +# example buildsystem macros for autotools Is autotools really so prominent to be part of defaults? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2774#pullrequestreview-1742207782 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] Declarative buildsystem, take II (PR #2774)
@voxik commented on this pull request. > @@ -1352,5 +1352,16 @@ end end } +# buildsystem defaults +%buildsystem_default_prep() %autosetup -p1 I don't see this to be documented. Is it something one should use for something? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2774#pullrequestreview-1742203368 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] External changelog integration (Discussion #2768)
So if they were scripts, the output of the script could be used as changelog / file list -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2768#discussioncomment-7590337 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] External changelog integration (Discussion #2768)
Can the `%changelog` section being made similar to others, such as `%prep`, `%build`, etc? Thinking of this, can `%files` section be more similar to those as well 樂 -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2768#discussioncomment-7580530 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] RFE: %{_system_bindir} and such macro (#721)
The thing is that I'll be fine if RPM does not provide any `_root` prefixed macros. But I'll be sad if Flatpak and RPMs will use different prefix for the same thing. You might leave this to SCL or Flatpak. OTOH, RPM is the common technology for both of them and the place where the technologies could unite and benefit from what RPM provides. I don't think there is any benefit if everybody needs to reinvent this from the ground once again. BTW I also agree that having available "pre-override" variants of macros might be nice from time to time :wink: -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/721#issuecomment-1810781199 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] RFE: %{_system_bindir} and such macro (#721)
> Adding a collection of `_root` macros then just seems like a "remedy" for bad
> packaging.
I don't care that much what the prefix is, but this kind of macros was
essential for SCLs, which allowed to have one source package, but the build
configuration changed the destination. In this scenario, there really needs to
be distinction between files from system or from some alternative destination.
And I believe the same applies to Flatpak.
But if you want to have philosophical discussion, then don't forget that
rpmbuild on itself is using this concept, where it is necessary to distinguish
between content from system and from `%{_builddir}` / `%{_buildroot}`
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/721#issuecomment-1810672005
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] [RFE] Please provide `%excludes` section (Issue #1852)
> I still don't like the duplicity, though
Neither do I. I just hope that my example is exceptional and the entry would be
enough to list in `%excludes` section in most of the cases
> Example of what I mean:
Huh, I think my brain is going to explode now thinking about the example
:exploding_head: But does it mean that this would include the file after all?
~~~
%files
%{gem_instdir}/config
%excludes
%{gem_instdir}/config
~~~
Also, I believe that your examples are not really equivalent. Because one of
the issues is that currently `%excludes` does exclude such item from package,
but does not exclude it from other processing (which is actually one of the
problems). This might also disqualify #2555
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1852#issuecomment-1787306967
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] [RFE] Please provide `%excludes` section (Issue #1852)
> > Note that the `%{gem_instdir}/config` is excluded form the main package,
> > but then it is not obvious if it should not be included elsewhere.
> > Therefore it is listed for the second time in the `%excludes` section to
> > make it clear it is not forgotten and it should really be excluded.
>
> This seems redundant, though. Why would you need an `%exclude` in the
> `%files` section at all in this case?
Please note that in this specific case, the whole `%{gem_instdir}` is included
in the package, except the `%{gem_instdir}/config` entry. However, it does not
make clear in global context if `%{gem_instdir}/config` should be included
elsewhere. To make it clear, it would need to be listed in other package or in
`%excludes` section, otherwise it would be reported as an error (similarly if
you miss some file).
IOW, this is to prevent mistakes.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1852#issuecomment-1787195946
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] Add "local_generator" (PR #2734)
> If `local_generator.attr` file exists then `local_generator` created twice. This is good point. Not sure if this is real problem though. > Why not simply create an empty `local_generator.attr` file instead? I have proposed this earlier in https://github.com/rpm-software-management/rpm/issues/782#issuecomment-1747200612 and put this idea into practice for [Fedora](https://src.fedoraproject.org/rpms/rpm-local-generator-support). I have no preference. I just wanted to move this forward a bit ;) now I stand by waiting for guidance (i.e. the right implementation and the acceptable name). -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2734#issuecomment-1782567947 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] Add "local_generator" (PR #2734)
@voxik commented on this pull request.
> char *bn = basename(files[i]);
bn[strlen(bn)-strlen(".attr")] = '\0';
fc->atypes[i] = rpmfcAttrNew(bn);
}
+ fc->atypes[nattrs - 1] = rpmfcAttrNew("local_generator");
The `nfiles` could be used here instead, but I am not sure it would make the
code more readable.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2734#pullrequestreview-1696861838
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] Add "local_generator" (PR #2734)
> I have to say, there's beauty to the simplicity of this. Would be even > simpler if the new generator was added as the last thing to the array I think. Done. On top of that, I have added also some test case. The other generator abuses `script.attr` AFAICT. Or shell the other test cases be updated to not abuse `script.attr` anymore? 樂 I have still left the `local_generator` name around, because it seems there is no clear winner yet -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2734#issuecomment-1778907220 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] Add "local_generator" (PR #2734)
@voxik pushed 1 commit. 61bd40a9df5170da6182e560d172fb16f4e3213b Add "local_generator" -- View it on GitHub: https://github.com/rpm-software-management/rpm/pull/2734/files/8a532b24e527f48cc45f7f49fc24d6fc4be39d49..61bd40a9df5170da6182e560d172fb16f4e3213b 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] Add "local_generator" (PR #2734)
@voxik pushed 1 commit. 8a532b24e527f48cc45f7f49fc24d6fc4be39d49 Add "local_generator" -- View it on GitHub: https://github.com/rpm-software-management/rpm/pull/2734/files/33c10c89387b168bceaa93ee2be7c6210a90aa2e..8a532b24e527f48cc45f7f49fc24d6fc4be39d49 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] Add "local_generator" (PR #2734)
@voxik pushed 1 commit. 33c10c89387b168bceaa93ee2be7c6210a90aa2e Add "local_generator" -- View it on GitHub: https://github.com/rpm-software-management/rpm/pull/2734/files/4b04cc38167dd637c3c1f68bf6d858453ccf24a1..33c10c89387b168bceaa93ee2be7c6210a90aa2e 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] Add "local_generator" (PR #2734)
> > Subject to name-bikeshedding of course. "local_generator" is not a bad for > > what it is, but my head keeps coming up with spec_somethings instead (and > > then rejecting) > > This is the hardest think, right :( And that is why I have also considered the `find` name, which was already used in this context. But of course this might be confusing ... -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2734#issuecomment-1777647182 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] Add "local_generator" (PR #2734)
> I have to say, there's beauty to the simplicity of this. Would be even > simpler if the new generator was added as the last thing to the array I think. That is an option. Will look at it tomorrow > Subject to name-bikeshedding of course. "local_generator" is not a bad for > what it is, but my head keeps coming up with spec_somethings instead (and > then rejecting) This is the hardest think, right :( -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2734#issuecomment-1777641462 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] Add "local_generator" (PR #2734)
This generator can be used by .spec file, which ships their own generators:
~~~
Source1: generator.req
%global __local_generator_requires bash %{SOURCE1}
~~~
Resolves #782
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/2734
-- Commit Summary --
* Add local_generator
-- File Changes --
M build/rpmfc.c (7)
-- Patch Links --
https://github.com/rpm-software-management/rpm/pull/2734.patch
https://github.com/rpm-software-management/rpm/pull/2734.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2734
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] Implement prepend and append modes for all our normal build scriptlets (PR #2728)
@voxik commented on this pull request. On tests/data/SPECS/append.spec: s/append.spec/append-prepend.spec/? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2728#pullrequestreview-1689710331 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] Implement prepend and append modes for all our normal build scriptlets (PR #2728)
@voxik commented on this pull request. > @@ -461,6 +461,13 @@ when name is omitted, the description refers to the main > package. Package build is divided into multiple separate steps, each executed in a separate shell. +Only one of each section can be present in a spec, but all build scriptlets +except for `%prep` accept options `-a` and `-p`, for append and prepend mode. +Append and prepend append or prepend lines to the section in the order they +appear in the spec. Both append and prepend can be used multiple times and +without other restrictions, but a section without either mode can only +appear first (eg `%build` cannot follow `%build -p`). This feels artificial to me. Not mentioning that the attached test case does not contain `%install` section as far as I can see. So how it is supposed to work in this case? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2728#pullrequestreview-1689709351 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] Implement prepend and append modes for all our normal build scriptlets (PR #2728)
@voxik commented on this pull request. > @@ -461,6 +461,13 @@ when name is omitted, the description refers to the main > package. Package build is divided into multiple separate steps, each executed in a separate shell. +Only one of each section can be present in a spec, but all build scriptlets +except for `%prep` accept options `-a` and `-p`, for append and prepend mode. +Append and prepend append or prepend lines to the section in the order they 3 times mentioning "append / prepend" in one place is a bit too much, isn't it? :) -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2728#pullrequestreview-1689698456 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
