Merged #2405 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2405#event-11756200361
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
@pmatilai commented on this pull request.
> @@ -2413,6 +2414,7 @@ runroot rpm -q --provides -p
> /build/RPMS/noarch/bcondtest-1.0-1.noarch.rpm |
],
[])
+
Couple of unrelated empty lines getting added here and above, and also just
before and between the new tests. It's a good idea to
@ffesti pushed 1 commit.
4d06f5559d55db81176a336b1f2b4259ecfa89e2 Allow to specify a default for bcond
features in a macro file
--
View it on GitHub:
@dmnks commented on this pull request.
> @@ -2451,6 +2453,105 @@ has_bcond(normally_on)
[])
RPMTEST_CLEANUP
+
+
+AT_SETUP([bcond_override_default macros])
+AT_KEYWORDS([bcond build])
+RPMDB_INIT
+
+# check bcond_override_default by defining
+AT_CHECK([
AT_CHECK is deprecated in favor of
And here we go. From 2 lines to 120 in just 11 months...
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2405#issuecomment-1934145866
You are receiving this because you are subscribed to this thread.
Message ID:
@ffesti pushed 1 commit.
fd34246f90bd101274c18adae485c1b430dcf5d6 Allow to specify a default for bcond
features in a macro file
--
View it on GitHub:
@ffesti pushed 1 commit.
7bd59e2a6146da8765a091dad197a7bcd1df4013 Update
docs/manual/conditionalbuilds.md
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2405/files/5eee9f7e9194288a7fde10f095861fa0364ebdad..7bd59e2a6146da8765a091dad197a7bcd1df4013
You are receiving
@ffesti commented on this pull request.
> @@ -91,5 +91,16 @@ macros which is nicer in other situations, e.g.:
Always test for the `with`-condition, not the `without`-counterpart!
+## Overrinding Defaults
+
+For distributions it can be useful to overwrite the build conditionals on a
global
I'll still want to see the "real-world" test cases added to this. The gotchas
and bugs are always in the part that you didn't think needs testing :laughing:
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2405#issuecomment-1929442665
@pmatilai commented on this pull request.
> @@ -91,5 +91,16 @@ macros which is nicer in other situations, e.g.:
Always test for the `with`-condition, not the `without`-counterpart!
+## Overrinding Defaults
+
+For distributions it can be useful to overwrite the build conditionals on a
@hroncok commented on this pull request.
> @@ -91,5 +91,16 @@ macros which is nicer in other situations, e.g.:
Always test for the `with`-condition, not the `without`-counterpart!
+## Overrinding Defaults
+
+For distributions it can be useful to overwrite the build conditionals on a
Yes.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2405#issuecomment-1929403698
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing list
Could you please add an example to the docs?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2405#issuecomment-1929392923
You are receiving this because you are subscribed to this thread.
Message ID:
OK, renamed to `bcond_override_default`. This is hopefully used sparingly
enough that the additional typing won't kill anyone.
I added some documentation to the Conditional Build page. This should answer
the questions above. But someone please prove read them.
--
Reply to this email directly
@ffesti pushed 1 commit.
dbb795984108e325841e8ca5c5c053c3dcd67731 Allow to specify a default for bcond
features in a macro file
--
View it on GitHub:
I'd like to see tests with real-world bconds in packages. We already have tests
for bcond so this can build on top of those.
I'd like to see documentation and tests on how this is supposed to be used in
real life, answering some practical matters like
- Where would the overrides/defaults be
Meditating a bit more over the name: May be "bcond_default" wasn't as bad as I
first thought as the macro does not override the users cli choice but only the
packagers default in the spec file. May be this is used seldomly enough to
afford "bcond_override_default"?
--
Reply to this email
@ffesti pushed 4 commits.
1df57c45c5cceee5c8b11170c2247dba529ad945 Allow to specify a default for bcond
features in a macro file
60a44efd320ded6880bc2d30bb925fe3edf4be12 Rename to bcond_override()
4c5d1f850ef0900df5ea6ecfe1d129c6a64f6284 Add test case
20f501d1ad08a4182326a9ef682b525c709b5a03
Guess we want `%__bcond_default` and `%bcond_default` for declaring the
`%bcond_default_foo` macro even if that is slightly silly.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2405#issuecomment-1919596356
You are receiving this
Well turns out this actually works. But may be not the way you expected... and
that's why we need docs.
As far as I understand this `%bcond_default` is just a helper macro (and should
be prepended with `__`) and the user/distro is supposed to declare
%bcond_default_foo manually. With that
This PR is wrong and is not solving th issue.
It is the problem that macros used with `%bcond_with foo`/`%bcond_without foo`
like `%{?with_foo}` and `%{?without_foo}` are using presence or not that macro.
If you will look closer on macros file
```spec
# Internally, the `--with foo` option defines
I think I like "override" better. Probably because it emphasizes the out of
order operation.
We also need to add this to `manual/conditionalbuilds.md` as soon as we decided
on a name.
--
Reply to this email directly or view it on GitHub:
This is indeed tricky because the desired flow of overrides is different from
the usual upstream < distro < host < user override order in rpm. What we have
here is something like packager < distro < user - there has to be a way to
locally build and override whatever the packager or distro
%bcond_set_libmpeg does not carry enough meaning. The other two proposals do
and I don't have a preference.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2405#issuecomment-1464010710
You are receiving this because you are subscribed to
Sorry for not commenting earlier, this was a busy week.
It's true that this can be done in the specfile, but that can lead to each
individual package maintainer using a different way. I think it's worthwhile
that the mechanism is the same for all distributions. The goal is exactly that
it
> Is putting something like `%bcond foo 0%{?default_foo}` in the spec file not
> an option?
Technically yes, but like bconds itself which are just syntactic sugar, it
would be nice to get something like this out of the box and working universally.
Currently the design of bconds makes them
I am confused by the nomenclature here. As a spec author, when I write:
```
%bcond tests 1
```
I expect the tests will run.
Now the distro maintainer (or anybody who can define macros, really) can define
a macro:
```
%bcond_default_tests 0
```
What happens to my package? Does it no longer
Is putting something like `%bcond foo 0%{?default_foo}` in the spec file not an
option?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2405#issuecomment-1453186692
You are receiving this because you are subscribed to this thread.
Nice. This is certainly a common need, I've seen activity around this topic on
Fedora/RHEL side as well but I've lost track as to where those efforts are now.
Tagging @hroncok and @encukou for past interest in this area.
--
Reply to this email directly or view it on GitHub:
The bcond mechanism of rpm allows to specify a default for a feature in a spec
file, which can be overridden with the command line. SUSE wants to build
packages with the same source in different projects. Thus we need a way to
specify a default via an rpm macro.
Our first try was to misuse the
30 matches
Mail list logo
