I have a set of packages with a clearly defined subpackage split: each
subpackage has a clear function distinct from the others. Reviewers feel that
one of those subpackages is slightly more important than the others and that
the srpm should be named after it.
However that totally breaks
Nope, the whole point of Markdown it that it can be used to express formatting
without complex formatting syntax. It's definitely **not** end-user legible
without some (slight) processing.
And if you say you're able do do formatting without those: just try to convert
the result to an appstream
I'm not sure rpm specs are shell oriented or not, the scriplets parts, sure,
the header/variable parts look more evolved custom config that any specific way
to do it to me.
And I have no problem with the scripts parts, they work well and are efficient,
I don't see the point of changing them.
The main problem I see is that current rpm does not like more than one -f flag,
and complex packages that mix several kinds of things would probably want more
than one of those. OTOH `%files` shows this is not a blocker.
And the script approach, while it allows calling several commands easily,
(But if that’s too hard to do please just do the `%buildrequires` part as
discussed before. We need it now. In fact we’ve been needing it for a decade at
least)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
What a wonderful idea. You’re right. *BuildRequires* are the current pain
point, but there's no reason the rest won’t want to be done after this problem
is fixed.
However I think the way rpm syntax tries to pretend rpm and srpm are symetrical
makes you miss the obvious. rpm and srpm are not
something not too long to type would be nice however
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
How about `%buildreqs` `checksreqs` `%prepreqs` `%installreqs` scheme?
Warning: I suck at naming
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
And the PR has been submitted:
https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/46
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
> The problem is that unlike %setup, %autosetup is a regular macro and doesn't
> really support multiple arguments of the same type - they're accepted but
> with "last one wins"-semantics:
That’s a case for https://github.com/rpm-software-management/rpm/issues/547
And adding lua argparse or
It could probably also be combined in some clever way with
https://github.com/rpm-software-management/rpm/issues/573
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
The desktop people keep inventing new ways to expose software descriptions to
users without actually reading rpm package descriptions (last iteration:
appstream files).
In theory upstreams are supposed to provide those files, in practice this is
massive overreach. Lots of upstreams do not give
RPM spec files are an hybrid between declarative and imperative syntax.
That's a wonderful design that weathered well the test of time but, the state
of the art progressed a lot since rpm syntax was defined.
The imperative shell part of spec files has already been completed with `%{lua:
}`
As seen in
https://github.com/rpm-software-management/rpm/issues/581
when you want to write some variable definition to a macro file, it gets
expanded by rpm. That usually does not matter but unfortunately, in some cases,
you really really want the expansion to occur when the file definition is
Sometimes macro packages need the macro definitions they ship in their own
spec file, before `%prep` is evaluated. This has led over the years to many
workarounds, to try solving this chicken-and-egg problem (sed from spec à la
fedora-release, shadow shell variables à la fontpackages,
Just drop this in /usr/lib/rpm/macro.d
```specfile
foo() %{lua:
print(rpm.expand("%{echo: start}"))
print(rpm.expand("%{echo: end}"))
}
```
and then call `%foo` in any part of the spec you want (I tested in `%prep`)
--
You are receiving this because you are subscribed to this thread.
Reply to
Right now if you let a single empty line pass within a `%{lua: }` block
`rpmbuild` will fail with the completely unintuitive *unterminated macro*
error. Unintuitive because the block is clearly terminated with a `}`, the
`rpmbuild` parser just gives up at the first empty line before reaching
> One thing that concerns me is that now when srpms require certain packages,
> this information is visible from the source repo. I can run repoquery to
> check that nothing requires what I intent to orphan etc. If we generate
> those, we should make sure the srpms we put in the source repo
Well yes in theory. In practice you never have enough info to debug a problem
quickly so a setup like `%prep`or `%build`where rpm echoes each executed line,
and where you can insert debugging printfs as needed, is pretty much ideal.
--
You are receiving this because you are subscribed to this
@ffesti
As a packager, I'd do it that way just because having stdout taken over sucks
from a debugging POW.
That's one of the things I dislike most about autoprovs: no easy way to put
debug statements to stdout when there is a problem (I've been known to write
autodep code that echos fake
@ffesti
So, just to be sure we understand ourselves, we could have something like:
```specfile
%prep
%buildrequires
cat buildrequires.lst
%build
```
That works for me. Nice clean simple and effective.
I assume the syntax of the lines outputted in `%buildrequires` would be the
same as
@praiskup
> -> we could simply print the list of BuildRequires to stdout (newline
> separated list of BRs).
>From a packager and macro writer POW a file like in %files -f is a bit simpler
>to manipulate – after a while one gets lost between the macro stdouts that are
>intended to write
@praiskup
> If I remember correctly, somebody
> suggested to do "fix-point" calculation (install dynamic BR in loop, till
> something gets installed - but I doubt this is needed in real world).
That was me and after playing with the concept for a year I agree you can live
without it in the
@ffesti
I thought the same thing as you at first but you don't absolutely need the
separate BuildRequires syntax. You can perfectly limit static BuildRequires to
the part needed to compute additional BuildRequires before `%build` and just
add any static BuildRequires needed for %build or
Anyway, to put things back into perspective, since I spent a one more year
trying to progress on the subject.
The constraints of a BuildRequires generator are the following:
1. you need to unpack sources
2. you need to fix those sources if they have problems so the generator gives
accurate
> > Unfortunately I've just seen another similar package wants to use the info
> > in the shipped macros to ExclusiveArch itself so that rules out using a
> > %prep method.
>
> This won't work at all. The ExclusiveArch goes to SRPM headers so by the time
> %prep is executed, it is already too
And of course then we'll hit
https://github.com/rpm-software-management/rpm/issues/551
because that will want to use the main workdir in `_builddir`, which should be
`%{buildsubdir}` except the way it is set is not ideal, and it is not set
before the end of `%prep'.
--
You are receiving this
Thanks a lot Panu, it like it a lot better than the shell script option!
Unfortunately I've just seen another similar package wants to use the info in
the shipped macros to `ExclusiveArch` itself so that rules out using a `%prep`
method.
I may end up replacing all this by sed-ing things in
https://src.fedoraproject.org/rpms/fontpackages/blob/master/f/fontpackages.spec#_84
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
You have 3 reproducers in
https://copr.fedorainfracloud.org/coprs/nim/rpm.572/builds/
The problem test is on line 80 of the macros.fonts file shipped in
fonts-rpm-macros built as part of fontpackages.
copr logs are not interesting, the fact rpmbuild -bs fails makes copr
completely blow up.
Thanks for the pointer!
However that does not help a lot when you are mass building in mock (the
general case nowadays), and the only debugging help are mock logs, and mock has
already cleaned up all rpm temporary files
--
You are receiving this because you are subscribed to this thread.
Well this is clearly doable in some form since whoever wrote the linked bit of
spec @rh did it.
The limitation seems to be that the result are shell variables not rpm
variables but from a practical POW the result is the same: the spec can use
values defined in macros it ships itself, and the
rpm is routinelly used to iterate over sources, patches, subpackages, etc in
spec files, but the original rpm design has no notion of lists of stuff.
This lack is workarounded by the `-n` flags in many original rpm clauses,
helpers such as `%patches`/`%sources`, lots of manual packager
RPM version 4.14.2
rpmbuild has a safety feature where it checks if Name/Summary/Source0 is
defined while processing a spec. Unfortunately, the check is not placed
correctly in the control flow.
So if you have a rpm macro that does something like:
```specfile
%{lua:
-- If %{name} does not
Anyway `%{shrink:...}` is no good for this.
What you'd want is something similar to
```sh
sed 's|^[[:blank:]]*$||g' | sed '/^$/N;/^\n$/D' | sed '/./,$!d' | tac | sed
'/./,$!d' | tac | fold -s
```
in a `%{text:...}` verb which is applied automatically to descriptions
--
You are receiving this
Right now `%{load: }` is unconditionnaly evaluated before `%prep` starts,
making it impossible to load a macro file present inside a source archive. That
adds quite a lot of complexity when you want to version-control a macro file in
an upstream macro project
`%{load: }` should be evaluated at
Of course Panu is right and the one kind of quoting I had forgotten to check
was the right one. *sigh* Thanks and sorry for the noise.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Alas the following filelist
```specfile
%doc %{quote:NeoHellenic Specimen.pdf}
%doc %{quote:OFL-FAQ.txt}
```
only results in
```shell
+ export LC_ALL=C
+ LC_ALL=C
+ export DOCDIR
+ /usr/bin/mkdir -p
What exactly is the contend in an empty duplicated line?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Yes there is such a clause. It does you no good if it’s not applied by default
to descriptions.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
(I should say that by the time rpm reaches this part in the code flow it has
probably several levels of imbricated expands to deal with)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Unfortunately, no, '`%%license` gives the same result as `%license` and
`%%%license` just prepends a `%` to the licensing tag value
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
So I have a versy large shell macro, inside an `%{expand}` because it’s full of
rpm variables that need interpetation, and I’m sick of the `\` game.
Among lots of other things, this macro needs to generale a `%license
` in file lists.
And of course that won't work because rpm will try to
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/568___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
A lot of effort has been expended to make attr setting unecessary in modern
rpm. Unfortunately, it seems to have forgotten ` %doc`, I see files packaged
with the 640 mask (as in the upstream archive) instead of 644.
--
You are receiving this because you are subscribed to this thread.
Reply to
When packaging something that needs multiple subpackages, one will typically
reuse part of the description. To reduce maintenance shores (fixing multiple
copies when an error is detected) this common block is typically put in an
expanded rpm variable
```specfile
%global common_description
That is completely unhelpful.
You can generate all you want you **will** have human packagers in the loop
(because upstreams are imprefect, so human intervention **is** required). And
as soon as you have humans in the loop you can **not** rely on everything being
generated by your code, and
rpmbuild should set `Version` to 0 by itself when not present in the spec,
instead of complaining
0 *is* the default version used in specs when none exists
The current system forces the creation of countless useless
```
Version: 0
```
lines
Those lines then confuse inexperienced packagers, who
> For example, the common case of a single well formed compresset tarball with
> a patch in a spec file is even simpler than your design:
>
> %prep
> %setup
> %patch
And that can be trivialy declined in
```specfile
%prep
%setup -z 0
%patch0
%setup -z 1
%patch1
%setup -z 2
%patch2
```
(of
A rather annoying "feature" of the current lua integration is that the lua code
is evaluated before executing any rpm section
So if you provide a lua macro that does not blindly pass arguments somewhere
else, but does some test or processing on them
```specfile
%luamacro somevalue
```
will
> > No it won't, the variable is not really set before %build
>
> NOW we're getting somewhere. %setup parsing certainly defines it, and this
> happens before any shell script is executed, but I see it gets lost somewhere
> in the cracks of %prep parsing. I can take a look at it, all I remember
> Since you asked, here's a small proposal and a possible alternative.
>
> Proposal: In a macro definition, using an argument string of `-` (as in
> `%define macro(-)`) indicates
> that getopt processing should not be done at all, and all supplied arguments
> and options should be
> delivered
> @nim-nim, but isn't that just about exactly what %setup by default does?
Not really, since the chainbuilding interferes `%setup` reuse with the next
archive
People just want to align
```specfile
%somesetup -z 1
%somesetup -z 2
%somesetup -z 3
```
Like they align path or source declarati
But that exposes to the macro user that some flags are handled by the rpm
argument parser and others by something else.
And that forces the macro user to use a specific flag order.
The macro user does not care about all this – that's a macro implementation
detail
--
You are receiving this
Panu, one huge reason `%setup` is still a mess after all this time it that it
is linked to the `SourceX` black magic. And yes rpmbuild will complain loudly
if you deviate from the way it thinks things should be done. And yes it will
refuse to process the resulting spec. And the documentation is
I don't doubt that's what the setup authors intended, but really, it's overly
clever for human beings, that like their commands simple and easy to remember,
it's overly clever for scripts, that like to loop over the same command not
compute complex lists of arguments, it's overly clever for
BTW
https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/35
does something similar for `%forgesetup`
Define an arbitrary number of sources, call `%forgesetup -a` in %prep, and
you're done
I didn't code a `%forgeautosetup -a` because I couldn't figure how to pass
correct patch
rpm convention is to put the main archive in SOURCE0 and ancilliary sources in
SOURCEX
(this way SOURCE0 is sure to exist and be stable, and can be aliased to SOURCE,
while the number of addons and their index can vary over a package time)
However rpm does not respect its own convention, sets
rpm macro argument parsing is ancient and limitating, it can not handle
full-word flags, it can not handle repeated flags, and so on
please add a syntax to specify a macro should not fail when used with a flag
not declared to rpm argument parsing, so all those new forms of arguments can
be
many commands nowadays accept multiple instances of the same flag (for example
dnf can take several -x flags with different values)
when you write a macro that calls such a command you want to use the same
syntax and have %{?-x} output all the -x flags
unfortunately rpm "helpfully" shortens
Right now rpm prints out lua syntax errors with line numbers, but forgets to
print the macro in which those lines can be found
When several lua macros call each other finding the one which is erroring
becomes quite tricky. rpm only points out the top macro name
--
You are receiving this
that's a bit of a strawman, that assumes spec + source is sufficient to
reproduce things
In the real life it's been known for a long time that the inputs needed to
reproduce is every single package installed in the build env. Starting with the
macro packages used.
(just try to rpmbuild -bs a
So, I can set SOURCE0, SOURCE1, etc as normal rpm variables in the spec, and
spectool will be happy, and download the corresponding sources.
HOWEVER rpmbuild won't be happy at all and will complain the spec does not
contain any Source tag
This is a PITA as it means computing SOURCEX values
> Seeing an existing example would really help to justify the additional
> complexity.
As I said, I don't have such an example (and hope won't have for some time).
It's just the kind of things I see upstreams do.
> Such problem smells like equivalent to bootstrapping distro from scratch
>
> I'm not sure calculating "fixed point" for build requires dependency graph is
> required in the first place. Having BuildRequires and then single-step
> dynamic build requires would be powerful enough I think, and easier to
> implement from buildsystem pov.
To be honest, I don't think I need
> Agreed. IMO rpm should just speficy "script" which prints build-requires to
> standard output. That can/could be: %build_requires # the script content
> /bin/awk ... do something or %build_requires -f
> or %build_requires -s . this way you don't
> have to adjust depsolver, only the
> Theoretically yes, but I don't think we have to go that far. Btw. the set of
> build-requires wouldn't be "constant" for each build of particular package
> and that would be big -1 from me (at least if you consider bootstrapping
> scenario where everything isn't completed yet). Whatever the
> Contrarian examples are trivial to devise. Consider an autoconf based
> generated file that builds if (and only if) certain files are detected. None
> of those BuildRequires can be automated and generated during a spec file
> parse with a pipe/file redirection.
That's more or less the Go
@ffesti You're complicating things unecessary, rpm does not distinguish between
manual and dynamic provides, there's no need to distinguish between manual and
dynamic BuildRequires either
In a dynamic BuildRequires world, the spec still contains static BuildRequires
(sufficient to pull in the
> Surely you do not mean that literally, where the directory name has, say, the
> suffix ".tar.gz"
> or ".zip" appended in the directory name.
Yes, sure, that was shorthand, the issue text is more explicit
> Also note that SourceN: is used for content that may not be an archive at all.
Then
You have build your toolset around rpm quirks in the meanwhile in the actual
world that almost never happens
And I've been using rpm for two decades (if you want a pissing contest)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on
Right now rpm assumes it can scrap the archivex filename from SourceX, but
nowadays many upstreams publish source archives on URLs that do not contain the
actual archive name*
The common workaround is to change SourceX to url#/archivex filename, but that
is quite confusing to new packagers and
Ok, I'm closing this one for now. Thanks everyone
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Well, the macro I'm working on for Fedora already pretty much does "builds on a
public branch, downloaded through https, on a tagged/documented check-in
located in an upstream VCS repository"
It does not use a magic URL but clear commit/tag variables like other
git-oriented tools like godep
Thank you for the additional info! I will look at it.
I'm not overly interested in building directly from VCS since that's security
hell (both from the auth POW and the protocol filtering POW). Supporting
building from github/gitlab/whatever https auto-tarballs is good enough for me.
In fact
That works, thanks, I didn't know about this syntax before !
`rpm.define("setup %%setup %{?setupargs}")`
I don't understand 'use a parameterized macro if necessary to eat existing
arguments/options' however. Can you provide a simple example?
--
You are receiving this because you are
I know it's utterly unglamorous, but the basic need is quite simple
- be able to append `-c` to `%setup` from the start of the specfile when a
software publishing service produces sources archives without inner topdir
- be able to append `-n computed-value` from the start of the when a software
The problem with automated (sub)package generators is that
1. you have upstreams from hell like TeXLive that bundle many many unrelated
parts of the same kind.
So you need some way to tell rpm "autocreate subpackages but split them around
those fileset lines"
2. you still need to declare
%setup is a wonderful macro but is shows its age. Massive software ecosystems
(such as GitHub) no longer release software in archives that conform to the
conventions %setup expect.
Nowadays spec writers need to spend a lot of time adapting spec headers to new
release conventions, and they are
101 - 179 of 179 matches
Mail list logo
