On 10/16/2017 06:22 PM, Richard Brown wrote:
On Fri, 2017-10-13 at 11:31 +0300, Panu Matilainen wrote:
The database path has always been trivially configurable with a macro
without having to patch rpm, nobody is taking that away. And because
it's so trivial to change it really doesn't need a configure switch either.
It's also way, way early to discuss about changing defaults. For that,
there needs to be at least
a) a viable new location (which is what I think this discussion is about)
And unless I'm reading the thread wrong so far, the consensus seems to be that
/usr/lib/rpmdb is a viable new
location for those who have use cases where /var is problematic.
Also it seems to be generally agreed that is arguably 'more viable' than
options like /usr/share/rpm
Does anyone feel I'm reading the feeling of the list wrong, or does anyone have
a different opinion?
Well you skipped my alternative suggestion entirely.
I don't see /usr/lib as a *good* place for this, but if a new top level
directory in /usr seems too much then maybe /usr/lib/sysimage or such
(and then rpm/rpmdb under that) would be a reasonable compromise. The
point is, rpm is not the only thing with data like this so it'd make
sense to have a common home for them all, instead of adding separate
/usr/lib/foo directories for each.
b) a way to handle migration in a reasonably transparent manner
In openSUSE/SLE we're going to handle this in the spec file for our rpm package.
https://build.opensuse.org/package/rdiff/Base:System/rpm?linkrev=base&rev=404
To describe it simply, we're doing the following
- in %post, if we identify that /var/lib/rpm is not a symlink & contains a
rpmdb, we create a symlink for
/usr/lib/rpmdb to the existing db. This ensures any scriptlets or such calling
'rpm' in the same transaction
will still be able to read their database.
- in %posttrans, if we identify that /var/lib/rpm is not a symlink & contains
an rpmdb, we remove the
/usr/lib/rpmdb symlink made in %post, create a folder, and mv the db to that
folder. We then rmdir
/var/lib/rpm and replace it with a symlink to the new /usr/lib/rpmdb location
And that's it. It's proven to be reasonably transparent in all of my testing
thusfar, though as this change is
now on the way to openSUSE Tumbleweed it's possible something will shake loose.
Thoughts/Comments/Feedback welcome.
As rpm doesn't provide an example specfile and leaves things like database
initialisation to distributions, I
suppose the best way would be to document the above method for those relocating
their rpmdb.
By handling migration I meant rpm upstream code, not spec kludgery.
Precisely because specs are distro-specific.
Where/how would be the best way for me to do that?
c) a reason with actual benefits to majority of users (that's what
*defaults* are about)
While the rpm-ostree and snapper use cases hit against this most painfully, I
actually don't buy the argument
that the majority of users would not benefit from this change.
I've been administering rpm managed systems for more years than I'd like to
count, and /var/lib/rpm has often
been the only thing in /var which I've had to pay extra attention to when
backing up and restoring a system.
I personally think having the rpmdb under /usr will dramatically simplify the
ease of backup and restore of
the 'system state' of the majority of users on the majority of distributions,
because we'll basically be able
to clearly say that /var does not include any 'system state' information and
only needs to be backed
up/restored according to the needs of the specific services that use it.
I love the idea of having var-less system backups again and rpm is the only
tool I can think of on the
distributions I'm familiar with that is impeding this.
As Neal pointed out, there's dpkg and the other package management
systems that put their stuff in /var too. And you don't need to go even
outside the rpm land for those other things, there's yum/dnf/PackageKit
(and who knows what else) that keep their own databases on
install-related information in /var.
- Panu -
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
