-- Originally written by Jason Tibbitts <ti...@math.uh.edu> in 2016.
-- Donated to the public domain. If you require a statement of license, please
-- consider this work to be licensed as "CC0 Universal", any version you
-- choose.
-- My hope is that other distributions, or RPM it
My understanding is that the later definition simply overrides the former. But
I would expect that conventions for namespacing would work to prevent
accidental conflicts and if you can't redefine then you would just use
functions in a namespace. I don't see why that would be mandatory, though
These are pretty minor but they do all seem to me to be reasonably good ideas.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Various options:
* Fedora could simply patch this downstream; it's just one popt file.
* RPM could leave the Group field in the header empty instead of hardcoding
"Unspecified". Then the popt file could just conditionally include the line.
I've no idea what else would break, though.
* The
What about anything that calls `%autosetup`? You have to stop somewhere.
Better would be to give sufficient expressiveness to the macro language to
handle repeated arguments, and perhaps not need magic internal macros at all.
Or maybe just add a Lua argument parsing library as standard and
What we're trying to get around is having to do `%define
foo(abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ)` so that the macro
can just handle parsing `%**` itself, and then still not being able to handle
anything that looks like a long option. That hack allows repeated arguments,
But that only shows that @pmatilai's point was correct: If you need to do
something dynamically in the build scriptlets, you need to do it with the shell.
That bit of the spec does things via the shell. So, yes, it's clearly doable
in some form: with the shell.
I don't understand how what
It would be far more useful if you could simply provide a few short specfiles
which illustrate the problem you are having. I don't think you can reasonably
expect the upstream RPM developers (or anyone else, really) to dig through that
copr URL to try and figure out what in there might
I though this might show it, but to me it looks like it works as expected;
using either three or four percent signs seems correct. (That's kind of a fun
result on its own, though.) Maybe your situation is more complicated or more
nesting is required or something. That's why it's really
Hey, this was just pointed out to me, and it seems to perfectly provide a
solution to a problem.
As many might be aware, the Fedora packaging committee has periodically taken
up the issue of using tilde Version:. And I've been putting in a load of
effort trying to come up with a consistent
Indeed, that's pretty much completely unpossible. Though if %luamacro takes no
arguments and expands to shell code then of course that works to some degree.
It may even work as you want to work. You just have to be very careful about
where the line breaks are in the emitted shell code.
--
Indeed, thanks.
--
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/321#issuecomment-442258681___
Rpm-maint mailing list
This just reveals how redefining of %_bindir (or I guess more correctly they're
redefining %_prefix) is not an ideal solution to the problem they're facing. I
honestly have no problem with specifying a full path in a build dependency in
the case that you can't for some reason specify a package
This sort of seems the kind of thing that would go in to redhat-rpm-config (or
another distro-specific package) first instead of straight upstream to RPM.
But I guess I don't fully understand how new macros are expected to flow into
RPM these days.
--
You are receiving this because you are
jasontibbitts commented on this pull request.
> @@ -335,16 +335,16 @@ package or when debugging this package.\
# A colon separated list of desired locales to be installed;
# "all" means install all locale specific files.
-#
Why give someone a reason to reject this just
Looking further, it appears to me that %buildarch isn't even defined until RPM
sees `BuildArch: noarch` somewhere in the spec. At that point it gets defined
to noarch and stays there. I don't know what utility that particular behavior
has.
--
You are receiving this because you are
I'm trying to better understand how %buildarch works in the case of multiple
%package declarations. For more context, see
https://bugzilla.redhat.com/show_bug.cgi?id=1705656
Basically, it appears that as soon as BuildArch: noarch is seen anywhere, the
value of %buildarch changes to "noarch"
Thanks!
--
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/776#issuecomment-510657558___
Rpm-maint mailing list
This would probably be better as an rpmlint check, except then it might be
ignored.
Certainly from RPM's perspective, having a %pretrans scriptlet written in shell
or anything else is perfectly valid. Only a distro like Fedora which cares
about every package being installable into an empty
I noticed a package (verilator) in Fedora that provides "2018-03-17". Turns
out that it installs a pkgconfig file which contains `Version: 3.922
2018-03-17`, which causes `pkgconfigdeps.sh -P` to output `pkgconfig(verilator)
= 3.922 2018-03-17`.
Looking through various documents about
Thanks, all. In the meantime the bizarre extra Provides: bit doesn't really
hurt anything.
One interesting side effect is that I'm not sure anything in Fedora would
actually ever validate any of the installed pkgconf files. I wonder if this is
a reasonable candidate for a brp script. (It
I do think this could be useful if it would serve to reduce packager workload,
though the trend seems to be moving away from scriptlets in general.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
I don't believe it's that easy if you don't already have a `.attr` file. It
doesn't look to me as if RPM will look at `%__foo_magic` or `%_foo_provides`
unless it sees `%_fileattrsdir/foo.attr` first. Of course, you could override
`%_fileattrsdir` instead, but then you would have to copy the
I recently helped track down a rather bizarre build failure, where rpmbuild
exited 1 (causing mock to abort) but it wasn't really obvious why. Turns out
that executable permissions had been removed from a directory. (Upstream had
added a directory where previously there were only files, and
Since what you really want is a significantly different total ordering, you
really need a different set of binary relations. I certainly don't want to be
the one to propose `<~`, `<=~, `>~`, and `>=~`. Plus, for completeness, I
guess you'd need a comparison operator `=~`. That would all
jasontibbitts commented on this pull request.
> @@ -1073,7 +1073,8 @@ package or when debugging this package.\
#--
# The "make" analogue, hiding the _smp_mflags magic from specs
-%make_build %{__make}
If I didn't screw this up, it should help with #798. It just pulls the `V=1
VERBOSE=1` bit out to a separate macro to make it easier to override.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/799
-- Commit Summary --
*
One of the packages I help maintain (apcupsd) broke oddly in rawhide with
errors like this:
```
/bin/sh: 1man: command not found
make[3]: 1g++: Command not found
```
Turns out this comes from the `V=1` which was added to `%make_build` in
8655493bdfd6b76271893b148033f2ff580d2d39. The software
Oh, this would be so great.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1063#issuecomment-585008636___
Rpm-maint mailing
Wow, this is quite interesting and somewhat similar to things I've brainstormed
about for a number of years now I think that this has the possibility to
simplify packaging for a significant portion of at least the Fedora packaging
set.
However, one problem we've struggled with is that when
I personally agree that it can be confusing, but I can't think of any technical
reason why RPM would actively prevent it from working. I think this is more of
a distribution issue; different distributions can choose to enforce different
guidelines for stylistic issues such as these if they
I was just poking at this the other day after years of seeing that bit at the
end of the RPM Lua documentation. Lua has reasonable pattern matching even if
it's a bit weird, and it should suffice for most things.
--
You are receiving this because you are subscribed to this thread.
Reply to
32 matches
Mail list logo
