Just to xref, since this one was closed the current plan is for rpm-ostree to
wrap rpm, instead of having rpm wrap rpm-ostree:
https://github.com/coreos/rpm-ostree/pull/1789
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
NAK for polluting main rpm code with rpm-ostree specifics, and lockfile
creation seems like the wrong place to do that anyhow.
The place for this kind of material is an rpm plugin which some rpm-ostree
component depends on it so its there when needed without bothering others.
--
You are
Closed #320.
--
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/320#event-1242604735___
Rpm-maint mailing list
> @cgwalters: This patch looks very specific to RPM-OSTree. Is there not a
> better, more general way to do this?
More general to...other image systems that happen to use rpm? Possibly. As
far as I'm aware though rpm-ostree is fairly unique in the way it's a hybrid
image/package system. I
@cgwalters nagware never works.
if ostree permits live update even with -EROFS, then your patch should teach
rpm to do similar live-update, not spew nagware adverts.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@cgwalters: This patch looks very specific to RPM-OSTree. Is there not a
better, more general way to do this?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
BTW, down the line I'd like to extend this ostree-detection functionality a bit
more so that e.g. `rpm -V` understands that timestamps are different, and
that's OK.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Hi @herrold - I read your comment a few times and I'm confused...isn't that
what my patch is doing?
BTW, it's easy to try an rpm-ostree based system, see
https://getfedora.org/atomic/ and https://pagure.io/workstation-ostree-config
for example. One thing I'd note though is that the rpm
As I understand the model for rpm-ostree, it assumes a Read Only, and
re-located RPMDB
Wouldn't a more general fix than the one seemingly already committed about
inability to calculate TS disk size requirements, be a simply attempt to
connect with the BDB and get a lockfile? this would
This PR rolls in https://github.com/rpm-software-management/rpm/pull/319
After:
```
# rpm -e atomic
error: This system is managed by rpm-ostree
error: can't create transaction lock on /var/lib/rpm/.rpm.lock (Read-only file
system)
```
This is still a WIP/RFE - the code here isn't pretty
10 matches
Mail list logo
