I made some test unit for that issue.
test-replace-directory-1.0 package has in /mnt/file directory /mnt/file/file.
Than 2.0 has only /mnt/file file.
Here is result:
[root@barrel RPMS]# rpm -ivh test-replace-directory-1.0-1.x86_64.rpm
Verifying...
It's easier (and less error-prone) to change incompatible behavior [in a single
spot](https://github.com/ascherer/cwebbin/blob/master/cwebbin.spec#L54), e.g.,
when switching from GNU/Linux to macOS.
--
You are receiving this because you are subscribed to this thread.
Reply to this email
If there was macro `%repelace_text_in_file_inplace` which would have defined
output, I could see a benefit. But claiming that `sed -i` is not universal and
replacing it with macro `%__sed_i` does not make any sense to me.
--
You are receiving this because you are subscribed to this thread.
@mlschroe Thank you that works (even if it’s not too intuitive)
Unfortunately the end result did not work out, due to the usual differences in
evaluation time between the rpm and shell layer :( So I guess it’s back to
doing things in the wrong section, or using a file to pass data, for me.
--
Closed #960.
--
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/960#event-2846800783___
Rpm-maint mailing list
> And how about 15 years from now?
IMHO:
- Whatever storage engine was chosen now, this choice will look suboptimal in
15-25 years.
- The right strategy is to be able to choose easily, rather than trying to
choose the best engine "now & forever".
- A good tactic might be to add/replace an
Detecting SSDs automatically is a great step IMHO. This will in the end result
in may be half a dozen OS specific code pieces in `getRotational()`. That's
fine with me.
Not setting these config macros is probably the best way to set those values to
"autodetect" which should be the default
I don't know what you mean by that. Other than, "yes that's the caveat in the
description."
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
And how about 15 years from now? That's the kind of longevity that rpm needs
from the database engines.
It's good to see new potential alternatives emerge. But to set the expectations
straight, rpm is not in the business of pioneering database engines, our main
interest is in technologies that
Hello,
I have encountered problem with rpmbuild -br and dependencies during dynamic
buildrequires. It returns 11 even though all dependencies are satisfied.
How to reproduce:
I have this .spec file:
That's because of --nodeps. it does not check deps, so it always wants to give
you nosrc.rpm
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Originally reported at https://bugzilla.redhat.com/show_bug.cgi?id=1184126,
just copying here to move it upstream where it belongs:
---
Description of problem:
systemd sets ACLs on /var/log/journal to allow members of the wheel and adm
groups to read log files, owned by systed-journal user.
> The thing is, the rpmdb is unlike your average database. People expect to be
> able to access it both backwards and forwards in time across chroots,
> containers for builds, software inventory and whatnot. And when that ability
> is taken away (by introducing a new engine, or just an
The thing is, the rpmdb is unlike your average database. People expect to be
able to access it both backwards and forwards in time across chroots,
containers for builds, software inventory and whatnot. And when that ability is
taken away (by introducing a new engine, or just an incompatible
Rotational disks only hold us back if they're part of the transaction even in
this implementation, so I doubt that's a big issue.
Ultimately we'd want per-fs capability tracking to cover device- and
fs-specific issues, all the way down to fsm. That's one deep rabbit hole...
--
You are
Recent rpm versions have no problem supporting multiple backends and converting
between them on the fly, that's a fairly obvious pre-requisite for ever getting
off BDB in the first place.
And yeah I noticed the mentions of "MithrilDB" development with API and format
considerations and that's
Wouldn't `%expand` work here? (Note that `suffix` is already used in rpm...)
```
%{expand:%%global something%{suff} value}
```
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Originally reports include but are by no means limited to:
https://bugzilla.redhat.com/show_bug.cgi?id=1358861
https://bugzilla.redhat.com/show_bug.cgi?id=247239
https://bugzilla.redhat.com/show_bug.cgi?id=439290
Already moved to upstream tracking at least once in the Trac days
Do we have to bind the nosrc.rpm with exit status 11?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
19 matches
Mail list logo
