For a path, maybe this is where we finally introduce `/usr/lib/sysimage` as an
expected path. I could see something like `/usr/lib/sysimage/rpm-config` be a
valid location to store a whole hierarchy of pristine config files.
--
Reply to this email directly or view it on GitHub:
https://github.c
Ostree does something similar, too, maybe we could take a look at that as well:
https://docs.fedoraproject.org/en-US/fedora-silverblue/tips-and-tricks/#_working_with_ostreerpm_ostree
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1178#
This could also be a potential usecase for FA_REFLINK file-op that's been
tossed around in the PRs.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1178#issuecomment-1985509731
You are receiving this because you are subscribed to this t
This can probably be done as a plugin nowadays.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1178#issuecomment-1812090168
You are receiving this because you are subscribed to this thread.
Message ID: _
Lets just say I'm not at all convinced those copies should be visible in
queries at all, seems to me more like an internal implementation detail that
should be hidden away in the tooling. Also thinking that dealing with it
runtime allows far more flexibility in what to do with them and works wi
Regarding doing the copies at install time: The nice thing about having them as
normal files in the header is that we get automatic de-dup and refcounting.
I.e. we can do a 'rpm -qf ...' to find out the owners of a config file and they
get automatically removed if nobody owns them anymore.
We c
FWIW, I'm not hot about debconf at all, and rpm needs to stay true to its
non-interactive design.
However the ability to compare with and restore pristine configuration are
highly useful capabilities, it's almost embarrassing that rpm doesn't support
them.
--
You are receiving this because yo
That all depends... /var would be more appropriate for runtime created files,
/usr for packaged content.
--
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/1178#issuecomment
So this sounds like the beginnings of wanting to support something like debconf
on RPM. Interesting idea...
That said, I dispute putting it in `/usr/lib/rpm/config`. The standard location
for this stuff to exist should be in `/var/lib/rpm/config`. Basically, wherever
the rpmdb is, that's where
We could also create such copies at runtime to avoid duplicated content in
packages - most %config is small of course, but shipping dupes just seems ugly.
I've been dreaming of a git plugin for rpm config files for quite some time...
--
You are receiving this because you are subscribed to this
If a file is marked as config file, rpmbuild could automatically create a copy
and store it in `/usr/lib/rpm/config/first-digest-byte/file-digest`.
We can then make use of this to:
- allow to display the changes done by the user
- use a three-way merge algorithm
- handle digest algorithm changes
11 matches
Mail list logo
