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 recei
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
Rpm-maint@lists.rpm.o
> @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 g
@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:
https://
@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:
https://github.com/rpm-software-management/rpm/pull/320#issuecomme
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:
https://gi
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 databas
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 indicat
Down the line, it's likely that for rpm-ostree based systems we'll
install an interceptor for `/usr/bin/rpm` to redirect at least things
like local package installs. There's a lot of work to do for
that, so in the meantime let's help admins out by giving them a
helpful error message.
You can view,
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 obviousl
11 matches
Mail list logo