This will need at least a C API for adding aliases. And maybe look at the
bash-style alias thing too.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2722#issuecomment-1790269719
You are receiving this because you are subscribed to this
Writing anything package specific all into %{builddir} is a bad, bad idea. In
the default configuration, that directory is shared by all the packages built
by a user!
That said, we can revisit the matter once #2078 is done.
--
Reply to this email directly or view it on GitHub:
The need for macro arrays hasn't gone anywhere, even if the initial PR died of
old age.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1825#issuecomment-1790284946
You are receiving this because you are subscribed to this thread.
We never did an update on the 4.16 branch (4.16.2) and that release is now out
of support. Closing.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1762#issuecomment-1790671978
You are receiving this because you are subscribed to this
Closed #1762 as completed.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1762#event-10843597605
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
This is a bugfix update with a few small enhancements on top. Let me know if
Ive missed your favorite patch.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/2744
-- Commit Summary --
* Fix numberless T for thread number
Like noted above, there are various ways to achieve this already. If macro
arrays (#1825) ever get implemented, then this might become more
relevant/feasible. Closing for now though.
--
Reply to this email directly or view it on GitHub:
Closed #2028 as completed.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2028#event-10843586167
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
Pondering about this a little more, it really isn't an easyfix as it touches
some rather low level code. If it turns out to be important enough for a lot of
people, we can revisit but I'll just close now.
--
Reply to this email directly or view it on GitHub:
Closed #2180 as completed.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2180#event-10843586067
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
@ffesti I was wondering about ced4d24f0. Does it have any uses outside the
Dynamic spec feature?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2744#issuecomment-1790955338
You are receiving this because you are subscribed to this
No reproducer is available, closing now.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2376#issuecomment-1791020122
You are receiving this because you are subscribed to this thread.
Message ID:
Closed #1768 as completed.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1768#event-10843533706
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
Looks like the conclusion in 2021 was that `Obsoleted-by:` is not the solution.
Closing.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1768#issuecomment-1790663062
You are receiving this because you are subscribed to this thread.
Configure traditionally sets it to %{_prefix}/com which RPM has followed so
far. But this directory is not used anywhere and everybody changes the location
to /var/lib. As we are only changing the macro and not the configure default
this should be relatively save to do.
Resolves: #2092
You can
Closed #2455.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2455#event-10843736071
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mailing list
As per the ticket conclusion, sorry but NAK:
https://github.com/rpm-software-management/rpm/issues/2454
Apologies for taking so long with this.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2455#issuecomment-1790690888
You are
I agree that there should be more control over what files go where and the
current means given to the packagers are not that great. Having more special
code for creating sub packages is not something we want, though. We'd rather
give the packager the means to do that in the spec - or the build
Closed #1448 as completed.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1448#event-10843864415
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
Closed #2376 as completed.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2376#event-10846061102
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
The macro names here would be simply "%autobuild_build_opts",
"%autobuild_conf_opts" and so on, entirely predictable, and enforced by the
implementation. I agree tags *are* more, hmm, concrete somehow. I'll think
about it :+1:
--
Reply to this email directly or view it on GitHub:
Discussed this with the team to the same conclusion, closing.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2454#issuecomment-1790685429
You are receiving this because you are subscribed to this thread.
Message ID:
Closed #2454 as completed.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2454#event-10843698525
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
Actually the reason why it's safe in the rpm realm is that it *does* change the
default `%configure` parameter too. So with this change it's out of sync with
`./configure`, but then if somebody uses that and cares about this then they
should be passing in an explicit --sharedstatedir anyhow.
> Would it make sense to be able to expose some kind of simple way to pass
> options to the configure stanza? Autotools, CMake, and Meson at least all
> accept configure options, and it'd make sense to be able to do this without
> having to override the whole stage.
The thought crossed my mind
Why not define it as a field instead of a macro?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2620#issuecomment-1790520257
You are receiving this because you are subscribed to this thread.
Message ID:
You mean a spec tag, like `AutobuildConfOpts: --some-opts here`?
I dunno. The tags look even uglier to me than the macros, and macros is what
the implementations need to deal with anyhow.
--
Reply to this email directly or view it on GitHub:
There would need to be a way to pass options to all the autobuild macros, not
just conf. Because sometimes you need that extra FU=1 SOMEDIR=/there to a make
invocation etc, and ... of course the configure / make style line might not be
the last thing in the autobuild macro. And so .. maybe
> You mean a spec tag, like `AutobuildConfOpts: --some-opts here`? I dunno. The
> tags look even uglier to me than the macros, and macros is what the
> implementations need to deal with anyhow.
I guess, it's just that a spec tag field is standardized, whereas a macro is
not. Macro names can be
29 matches
Mail list logo
