> For rolling distributions were no consistent snapshot is used for building
> there is the need for an archive of all previous builds and a tool that
> selects the correct versions from the archive as the buildinfo says.
How is this handled in Debian? I know that they report certain
Forgot an additional complication: For rolling distributions were no consistent
snapshot is used for building there is the need for an archive of all previous
builds and a tool that selects the correct versions from the archive as the
buildinfo says.
--
Reply to this email directly or view it
AFAIK that is out of scope for rpm, but in the scope of tools that create build
roots, see
https://github.com/rpm-software-management/rpm/discussions/2654#discussioncomment-9060491
.
--
Reply to this email directly or view it on GitHub:
Bottom line: I'd like to have a reproducible "build environment" and a
reproducible "build process" that ensures that these nuances can be avoided and
the "build" will just work consistently every time. What I build: you can build
without asking questions and vice versa.
--
Reply to this
"Ideally, the NEVRA would indicate the vendor via the %_dist suffix."
- this does not handle builds for the different "EL" flavours. They **all**
tend to use **the same value**: `.el7`, `.el8`, `.el9`, etc and then again this
is not done consistently, there is no agreed specification of
In Fedora and openSUSE packages distribution variances are dealt with in the
spec by checking the content of distribution specific macros. These macros are
defined in packages shipped in the distribution and installed in the build
root. So using command line defines is really unusual. See
You should try to find out what too is used to build the build root for these
packages and use that if you can.
In both openSUSE and Debian a buildinfo file (though with different syntax) of
the the environment for the build is produced. This specifies environment
variables, packages installed
And we're live now with
https://github.com/rpm-software-management/rpm/pull/3028 :partying_face:
For the morbidly curious, there was certainly more to clean up before that, the
major preparatory work being in
https://github.com/rpm-software-management/rpm/pull/2977,
This is actually quite closely related to #2204 which we now *have to* fix.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1878#issuecomment-2044523111
You are receiving this because you are subscribed to this thread.
Message ID:
This beauty blocks %install -a/-p usage and doesn't work with Buildsystem: at
all, so it just went to the head of the priority queue.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2204#issuecomment-2044512305
You are receiving this
Merged #3028 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3028#event-12402731645
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
:see_no_evil:
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3028#issuecomment-2044380986
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing
Hmm, ugh. We have a test for this very scenario (%build -a) in the test-suite,
but looking closer indeed the buildsystem %build is lost. It's just that
autotools "make install" masks the issue by building automatically since not
already done. We also have bunch of other tests for -a/-p modes,
@pmatilai pushed 1 commit.
4e5b6d0c8886376d6e1ccc90e80db80f0953d3a5 Remove the WITH_CXX option, this is a
one-way street
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3028/files/70505942562da081e207ea908e090bc7e1c095ff..4e5b6d0c8886376d6e1ccc90e80db80f0953d3a5
You
This is (very) obviously a case of "things will get worse before they get
better", these casts are just unsightly but most will go away once converted to
actual native C++.
--
Reply to this email directly or view it on GitHub:
As per https://github.com/rpm-software-management/rpm/discussions/2983, here
goes.
More details in commits, but to summarize: add necessary casts to most of the
codebase to make it buildable with a c++ compiler, and then switch over to c++.
Exempt from this conversion are
- Python bindings:
Merged #3025 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3025#event-12401725294
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
17 matches
Mail list logo
