that's a good start at least. There's also --importdb. So with slightly more
code that could sync back and forth with a directory
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@lnussel If you want that, just write a post-transaction trigger to run `rpm
--exportdb` somewhere...
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Note that installing the headers on disk as part of package installation does
not exclude actually using one of the existing database formats.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Closed #1151.
--
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/1151#event-3204921026___
Rpm-maint mailing list
Would it be possible to implement a "filesystem" database backend? Most likely.
We've even tossed it around a few times between ourselves, but there's just
very little benefit and all manner of downsides, such as those @Conan-Kudo
already mentioned. I wouldn't call locking, atomic operations
> I have no insight to the other database formats so can't comment on how that
> is handled. For setups that never modify the running system but rather either
> prepare images or modify snapshots the transactional capabilities of rpm do
> not matter anyways. If anything goes wrong, no new
> * People can and will randomly manipulate files to force the package
> manager to do weird things (it's even documented in various troubleshooting
> guides)
Well, obfuscating the database for the purpose of avoiding people to mess with
it doesn't sound like an overly good motivation. RPM
This would essentially make it so rpm can behave the same way dpkg does, and
opens us to the same problems dpkg has:
* People can and will randomly manipulate files to force the package manager to
do weird things (it's even documented in various troubleshooting guides)
* It is not possible to
With uncompressed payload one could even copy the full rpm into
/usr/lib/sysimage/rpm/installed and reflink the data.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
How about not storing rpm headers in some binary database anymore but rather as
individual files on disk?
Ie rather than stuffing them into /usr/lib/sysimage/rpm/Packages.$format just
dump them as is, eg
/usr/lib/sysimage/rpm/installed/hello-1.2-3.x86_64.rpm
That opens several possibilities
-
10 matches
Mail list logo
