Defaulting to off would be as good as not existing. I already reverted it from
4.14 as it needs more time to bake, which is what git master is for. Not
reverting ATM.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://
Closed #318.
--
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/318#event-1238168421___
Rpm-maint mailing list
Rpm-maint@lists.rpm.o
There's surely prettier syntax that can be achieved, or alternative syntaxes
similar to what make does with conditional sections. E.g.
`%{!?_arch_x86_64:#}%foo bar`
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
htt
There's another approach to conditionalize macro definitions from configuration
by permitting existence tests in the first field.
Most of the usage cases that have been reported to me are based on
arch/os/platform, and the selection is being done by putting (some value) of
arch in path to selec
https://github.com/rpm-software-management/rpm/pull/318
--
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/commit/b7a869f0f322cbe428e78150f2c175abea4c8c4b#commitcomment-24120847
This reverts commit b7a869f0f322cbe428e78150f2c175abea4c8c4b.
This would need to be at a minimum configurable, and default to off for
compatibility with software like rpm-ostree that is already taking care of all
of this.
You can view, comment on, or merge this pull request online at:
https://g
BTW, see also https://github.com/ostreedev/ostree/pull/1049
--
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/commit/b7a869f0f322cbe428e78150f2c175abea4c8c4b#commitcomment-24120807
rpm-ostree also has its own `syncfs()` calls and we definitely don't want
librpm doing it.
--
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/commit/b7a869f0f322cbe428e78150f2c175a
See issue #258 for faster (and better: includes cache invalidation) than
sync(2).
--
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/commit/b7a869f0f322cbe428e78150f2c175abea4c8c4b
"... but what happened to the beta?", I hear you ask.
Well, we skipped it.
To cut to the chase, the highlights since the alpha include:
- Support for 'unless' rich dependencies
- Ensure header is present in callback events
- Macro argument quoting changed to be much more compatible
- Experiment
Yup - if you build with a --prefix different from the python used that happens.
Fixed by commit 4bb954086af48d0661e4a930d31517226e39db7b
--
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-managem
Closed #265.
--
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/265#event-1237001347___
Rpm-maint mailing list
Rpm-maint@lists.rpm
…text
Guide users to the correct operator instead.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/317
-- Commit Summary --
* Forbid 'if' richops in 'or' context and 'unless' richops in 'and' context
-- File Changes --
AFAIK, Docker is dumb and passes everything through to the host filesystem to
handle. So, yes...
--
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/commit/b7a869f0f322cbe428e78150f
But... a sync() from within a container does sync() on the entire host? Really?
--
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/commit/b7a869f0f322cbe428e78150f2c175abea4c8c4b#co
The problem with opt-in is that exactly nobody is going to configure it so it's
as good as useless.
--
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/commit/b7a869f0f322cbe428e781
It wouldn't, because RPM within docker doesn't know where it runs. So I would
rather for opt-in for this feature
--
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/commit/b7a869f0f
Disabling the sync automatically on chroot installations would be fine by me.
Would that cover the dockerd case?
--
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/commit/b7a869f0f
Eek, that's horrible. Please add a way (macro) to disable this.
Calling sync() hurts very much for big servers with huge disks and a big buffer
cache. I get that's it's somewhat acceptable for software installation on the
server (syncfs would still be much nicer so that data partitions don't get
19 matches
Mail list logo
