[opensuse-factory] RFC: Proposed relocation of /var/lib/rpm

newer
[opensuse-factory] New Tumbleweed...

older
[opensuse-factory] IBus icon after...

Richard Brown

4 Oct 2017 4 Oct '17

11:16

Hi all, Currently, rpm stores its rpmdb (the record of all a systems packages) in /var/lib/rpm Various openSUSE & SUSE distributions have a number of problems with this This has a major impact on our default btrfs snapshot & rollback feature. We need the contents of the rpmdb contained within the snapshots. This means /var/lib/rpm must be contained in the root snapshot in order to preserve the "system-state"; Without it a rolled-back system still thinks it has packages installed/removed which were changed as a result of the rollback. But /var and /var/lib both contain a great deal of data which we DO NOT want to include in the root snapshot; For example, we most certainly don't want snapper rolling back a database in /var/lib/mysql for example, and destroying user data in the process. Therefore we currently carry a rather complicated default list of subvolumes: https://en.opensuse.org/SDB:BTRFS#Default_Subvolumes This list contains a number of specific directories in /var/* we wish to preserve, which means it's almost continually out of date, leading to user data being at risk if we haven't made a specific subvolume for that data. The rpmdb is the only "system-state" information we have in /var which we need to preserve, making it quite a disruptive presence in the /var filesystem hierarchy. The problem is further complicated in *SUSE distributions that use a Read-Only root filesystem (eg. openSUSE Kubic & SUSE CaaS Platform) because it results in a situation where we really need to micromanage countless subvolumes under /var - any location we miss otherwise ends up read-only and packages can't write to the files they expect to be able to in /var Red Hat had a similar problem with their rpm-ostree tooling, which they solved by relocating the RPM database to /usr/share/rpm https://rpm-ostree.readthedocs.io/en/latest/#why-not-implement-these-changes... I would like to propose we adopt the same location for rpmdb in all *SUSE distributions This would mean we could make a single /var subvolume and dramatically simplify our btrfs configuration For systems with a read-only rootfs, /usr/share/rpm would be immutable and pristine, just as we require it to be. Our tooling should already be able to handle the new location without any major issues. For systems with a read-write rootfs, we will be slightly bending the rules of the FHS, in the sense that the FHS claims /usr should be 'read-only data' http://www.pathname.com/fhs/pub/fhs-2.3.html#THEUSRHIERARCHY However, installing packages routinely modifies the contents of /usr and it's various subdirectories, that is the nature of installing packages. Therefore it seems logical to me that the record of what is installed is also stored under the same conditions. I'm working on a patchset in an OBS home project to test this proposal and shake loose any issues, and will also be proposing this location change to rpm upstream. Therefore any comments are not only welcome, but the quicker the better, so I can factor them into what I'm doing. I would also like suggestions as how best to handle the migration of an existing rpmdb in /var/lib/rpm to it's new location in /usr/share/rpm, as I'm certain this is something we want to get absolutely perfect, and I'm understandably nervous about changing the rpmdb's location during an rpm transaction which will be altering the rpmdb. Thanks in advance, -- Richard Brown Linux Distribution Engineer - Future Technology Team Phone +4991174053-361 SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Show replies by date

Carlos E. R.

4 Oct 4 Oct

11:38

On 2017-10-04 13:16, Richard Brown wrote:

...

For systems with a read-write rootfs, we will be slightly bending the rules of the FHS, in the sense that the FHS claims /usr should be 'read-only data'

What about machines that share /usr from a central machine over the network? -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)

Richard Brown

12:05

On 4 October 2017 at 13:38, Carlos E. R. wrote:

...

On 2017-10-04 13:16, Richard Brown wrote:

...
For systems with a read-write rootfs, we will be slightly bending the rules of the FHS, in the sense that the FHS claims /usr should be 'read-only data'

What about machines that share /usr from a central machine over the network?

Putting the rpmdb in /usr/share is no worse than the current situation Right now machines sharing /usr from a central machine over the network are going to have an rpmdb that will contain an invalid picture of the contents of /usr Any person with root access to any machine accessing that shared /usr can attempt to install/remove packages. If the share is read-write that will currently lead to changes for all systems but only the system doing the installation will be aware of what it did and able to uninstall the rpms that changed /usr This will lead to untrackable inconsistencies in other areas of the filesystem, as only /usr is shared. If the share is read-only the rpm install will likely fail. With this proposed change any user with root access to a machine accessing a shared /usr will change the contents of /usr and update the (now shared) rpmdb While this can still lead to inconsistencies on other systems as only /usr will be shared, this will at least be 'trackable' as all systems with a shared /usr will now be able to verify what files they should have, where as currently they cannot. If the share is read-only, the rpm install will still fail, just as it would today. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Anton Aylward

14:47

On 04/10/17 08:05 AM, Richard Brown wrote:

...

On 4 October 2017 at 13:38, Carlos E. R. wrote:

...
On 2017-10-04 13:16, Richard Brown wrote:

...
For systems with a read-write rootfs, we will be slightly bending the rules of the FHS, in the sense that the FHS claims /usr should be 'read-only data'

What about machines that share /usr from a central machine over the network?

Putting the rpmdb in /usr/share is no worse than the current situation

Right now machines sharing /usr from a central machine over the network are going to have an rpmdb that will contain an invalid picture of the contents of /usr

That's a ridiculous straw-man argument, Richard. /usr/share was INTENDED quitre clearly and is there in the file ssytem definition/description to that end. No such for /usr

...

If the share is read-only the rpm install will likely fail.

100% true. And /usr/share being shared across machines, NFS or CIFS, is going to be read only for most of them. Heck, even when we had the old SU way of 'hoteling' and pretty dumb workstations where almost everyting was NFS, particualr the /home/$USER, it was the /etc/ that was ALWAYS machine-local and machine-specific.

...

With this proposed change any user with root access to a machine accessing a shared /usr will change the contents of /usr and update the (now shared) rpmdb

Which is why it should NOT be under /usr/share specifically. And why the database should be in a non-shared, machine specific location. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Martin Pluskal

5 Oct 5 Oct

07:52

On Wed, 2017-10-04 at 10:47 -0400, Anton Aylward wrote:

...

On 04/10/17 08:05 AM, Richard Brown wrote:

...
On 4 October 2017 at 13:38, Carlos E. R. wrote:

...
On 2017-10-04 13:16, Richard Brown wrote:

...
For systems with a read-write rootfs, we will be slightly bending the rules of the FHS, in the sense that the FHS claims /usr should be 'read-only data'

What about machines that share /usr from a central machine over the network?

Putting the rpmdb in /usr/share is no worse than the current situation

Right now machines sharing /usr from a central machine over the network are going to have an rpmdb that will contain an invalid picture of the contents of /usr

That's a ridiculous straw-man argument, Richard.

/usr/share was INTENDED quitre clearly and is there in the file ssytem definition/description to that end. Hi

And if I understand correctly, in such usecase machines sharing /usr/share have to be running basically identical system, and I would guess that they would be deployed via other means than by system installer - thus having rpm database in this location would not change much. Also I wonder if such usage is supported by openSUSE. Cheers Martin -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Marcus Hüwe

4 Oct 4 Oct

23:37

On 2017-10-04 14:05:53 +0200, Richard Brown wrote:

...

On 4 October 2017 at 13:38, Carlos E. R. wrote:

...
On 2017-10-04 13:16, Richard Brown wrote:

...
For systems with a read-write rootfs, we will be slightly bending the rules of the FHS, in the sense that the FHS claims /usr should be 'read-only data'

What about machines that share /usr from a central machine over the network?

Putting the rpmdb in /usr/share is no worse than the current situation

Right now machines sharing /usr from a central machine over the network are going to have an rpmdb that will contain an invalid picture of the contents of /usr

Any person with root access to any machine accessing that shared /usr can attempt to install/remove packages. If the share is read-write that will currently lead to changes for all systems but only the system doing the installation will be aware of what it did and able to uninstall the rpms that changed /usr

This will lead to untrackable inconsistencies in other areas of the filesystem, as only /usr is shared.

Hmm it depends a bit on the use case: if people want to share /usr (for whatever reason...) and have the rpmdb in /var/lib/rpm, they can still install 3rd party rpms, which only install files into /opt/*, without causing "inconsistencies" to the other systems' rpmdb. Anyway, this use case can still be realized with the new rpmdb location. Marcus -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Anton Aylward

14:38

On 04/10/17 07:38 AM, Carlos E. R. wrote:

...

On 2017-10-04 13:16, Richard Brown wrote:

...
For systems with a read-write rootfs, we will be slightly bending the rules of the FHS, in the sense that the FHS claims /usr should be 'read-only data'

What about machines that share /usr from a central machine over the network?

Indeed! This was the original purpose of /usr/share and many today still use it that way, consolidating centrally thing like the manual pages that apply EQUALLY to all machines. If you want a BtrFS rollback location /etc is better. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Richard Brown

14:41

On 4 October 2017 at 16:38, Anton Aylward wrote:

...

On 04/10/17 07:38 AM, Carlos E. R. wrote:

...
On 2017-10-04 13:16, Richard Brown wrote:

...
For systems with a read-write rootfs, we will be slightly bending the rules of the FHS, in the sense that the FHS claims /usr should be 'read-only data'

What about machines that share /usr from a central machine over the network?

Indeed! This was the original purpose of /usr/share and many today still use it that way, consolidating centrally thing like the manual pages that apply EQUALLY to all machines.

And in that situation, how do you ensure that the manual pages you're sharing are accurate for the version of binaries on the machines? (especially on openSUSE where we have lots of binaries that aren't in /usr atm). -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Anton Aylward

15:12

On 04/10/17 10:41 AM, Richard Brown wrote:

...

On 4 October 2017 at 16:38, Anton Aylward wrote:

...
On 04/10/17 07:38 AM, Carlos E. R. wrote:

...
On 2017-10-04 13:16, Richard Brown wrote:

...
For systems with a read-write rootfs, we will be slightly bending the rules of the FHS, in the sense that the FHS claims /usr should be 'read-only data'

What about machines that share /usr from a central machine over the network?

Indeed! This was the original purpose of /usr/share and many today still use it that way, consolidating centrally thing like the manual pages that apply EQUALLY to all machines.

And in that situation, how do you ensure that the manual pages you're sharing are accurate for the version of binaries on the machines? (especially on openSUSE where we have lots of binaries that aren't in /usr atm).

Again you've given a ridiculous straw-man argument, Richard. The reality is that the MAN packages are just plain weird anyway. Yes, some packages carry their own man pages. Good for them. But packages like 'man-pages' out of the main distribution repository address this. So the issue is not the "one /usr/share to rule them all". The "One X to rule them all" is an emergent attitude of the BtrFS supporters, as I've pointed out before. Oh, and there's "man-pages-posix", which leads to the next point. When I ask for a man page I get asked which one I want. In fact it get better. There the MANPATH environment variable. And out of the box it seems to put /usr/local/man first. oh WOW. So I can have yet-another "local" FS mounted that is SPECIFY TO MY MACHINE. I really really love the ability of Linux to customise this way. And even better, I could add /home/anton/man to the MANPATH to support the programs and scripts I've written for myself that in /home/anton/bin, and so available to me at whatever workstation on the network I choose to login in from. if your argument is about machine specific roll-back then the place to put the database is in the most machine specific place, and /usr/share is most certainly NOT that. Whereas /etc most certainly IS. Please stop coming up with these ridiculous straw-man arguments. They do you no credit, they just damage your credibility. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Thorsten Kukuk

15:01

On Wed, Oct 04, Anton Aylward wrote:

...

On 04/10/17 07:38 AM, Carlos E. R. wrote:

...
On 2017-10-04 13:16, Richard Brown wrote:

...
For systems with a read-write rootfs, we will be slightly bending the rules of the FHS, in the sense that the FHS claims /usr should be 'read-only data'

What about machines that share /usr from a central machine over the network?

Indeed! This was the original purpose of /usr/share and many today still use it that way, consolidating centrally thing like the manual pages that apply EQUALLY to all machines.

/usr/share is only for exact identically installations. The FHS clearly states that /usr/share is not shareable between different versions.

...

If you want a BtrFS rollback location /etc is better.

No, everything outside /usr is no option, why do you think did Red Hat choose a location on /usr? And this has nothing todo with Btrfs, it's a problem all rollback solutions have. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Anton Aylward

15:22

On 04/10/17 11:01 AM, Thorsten Kukuk wrote:

...

...
Indeed! This was the original purpose of /usr/share and many today still use it that way, consolidating centrally thing like the manual pages that apply EQUALLY to all machines.

...

/usr/share is only for exact identically installations. The FHS clearly states that /usr/share is not shareable between different versions.

Ah, we have a subtle semantic shift here. That was what I meant by "equally". Different architectures, different revisions, are not 'equal'. If you look to, for example the repositories for any distribution or the Packman repository at http://ftp.gwdg.de/pub/linux/packman/suse/ you can see that they accommodate "others". But my zypp.conf only uses one of those. And it gets better. Go up one level and Packman addressesdebian, fedora and ubuntu as well. Why would you imagine a server dishing out, for example, man pages, to be any less capable? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Marcus Rueckert

12:37

tbh ... /etc/rpm/db would be a path i could live with ... /usr/share/rpm feels wrong to me. this is a path where i would expect static data. darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Bruno Friedmann

12:52

On mercredi, 4 octobre 2017 14.37:01 h CEST Marcus Rueckert wrote:

...

tbh ... /etc/rpm/db would be a path i could live with ... /usr/share/rpm feels wrong to me. this is a path where i would expect static data.

darix

I feel the same, /etc being part of the rootfs and rpmdb being the "expression" of the perticular state of installed software of this computer, I found it more logical to find /etc/rpm/db But as I'm not that familiar with btrfs trick and so, I can have a biased view. btw in the wiki of subvolumes I guess /var/lib/dhcp should also be subvol due to the dhcpd db lease (which should be consitent with named one if dynamic dns is in used) otherwise TXT records will not be in sync. -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch Bareos Partner, openSUSE Member, fsfe fellowship GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Dominique Leuenberger / DimStar

12:59

On Wed, 2017-10-04 at 14:37 +0200, Marcus Rueckert wrote:

...

tbh ... /etc/rpm/db would be a path i could live with ... /usr/share/rpm feels wrong to me. this is a path where i would expect static data.

/etc feels wrong in different ways: the rpm db is not any file we expect an admin to go fiddle and change content of it Most correct would likely be /usr/lib/something - but what is the benefit over /usr/share (except improved feeling) compared to being able to share patchwork with another distro? Cheers Dominique

Marcus Rueckert

13:08

On 2017-10-04 12:59:34 +0000, Dominique Leuenberger / DimStar wrote:

...

On Wed, 2017-10-04 at 14:37 +0200, Marcus Rueckert wrote:

...
tbh ... /etc/rpm/db would be a path i could live with ... /usr/share/rpm feels wrong to me. this is a path where i would expect static data.

/etc feels wrong in different ways: the rpm db is not any file we expect an admin to go fiddle and change content of it

Most correct would likely be /usr/lib/something - but what is the benefit over /usr/share (except improved feeling) compared to being able to share patchwork with another distro?

/usr is more or less static for me. no modified data in it. /etc/ is configuration at least. and the admin *does* fiddle with the files in /etc/rpm/db/ ... via the rpm utility. not all files in /etc/ are being edited with $EDITOR. Just to name one example: tzselect. which also bring the question ... does someone have a reference to the fedora/redhat discussion about this subject? it might short cut the whole discussion. darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Thorsten Kukuk

13:17

On Wed, Oct 04, Marcus Rueckert wrote:

...

On 2017-10-04 12:59:34 +0000, Dominique Leuenberger / DimStar wrote:

...
On Wed, 2017-10-04 at 14:37 +0200, Marcus Rueckert wrote:

...
tbh ... /etc/rpm/db would be a path i could live with ... /usr/share/rpm feels wrong to me. this is a path where i would expect static data.

/etc feels wrong in different ways: the rpm db is not any file we expect an admin to go fiddle and change content of it

Most correct would likely be /usr/lib/something - but what is the benefit over /usr/share (except improved feeling) compared to being able to share patchwork with another distro?

/usr is more or less static for me. no modified data in it. /etc/ is configuration at least.

The RPM database is as static as any other file in /usr. It is only modified, if you modify files in /usr. It is not modified, if you modify files in /etc. So according to your own argumentation, the rpmdb should be in /usr. Beside that moving the rpm database to /etc does not solve any problem, but the result would be even worse than with /var/lib. And if somebody finally finishes the /bin -> /usr move, having the RPMDB outside of /usr doesn't make any sense anymore.

...

which also bring the question ... does someone have a reference to the fedora/redhat discussion about this subject? it might short cut the whole discussion.

I don't think there was any dicussion, Red Hat decided to do so for RPM-Ostree, since they had no choice. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Jan Engelhardt

14:31

On Wednesday 2017-10-04 15:17, Thorsten Kukuk wrote:

...

...
...
...
tbh ... /etc/rpm/db would be a path i could live with ... /usr/share/rpm feels wrong to me. this is a path where i would expect static data.

/etc feels wrong in different ways: the rpm db is not any file we expect an admin to go fiddle and change content of it

Most correct would likely be /usr/lib/something - but what is the benefit over /usr/share (except improved feeling) compared to being able to share patchwork with another distro?

/usr is more or less static for me. no modified data in it. /etc/ is configuration at least.

The RPM database is as static as any other file in /usr. It is only modified, if you modify files in /usr.

So that must have been the reason we had --sharedstatedir=/usr/com! ;-) ------------------------------------------------------------------- openSUSE:Factory/rpm/rpm.changes Wed Jul 5 16:28:46 CEST 2017 - ngompa13@gmail.com - Define %_sharedstatedir as /var/lib, which is the path for shared state content in Red Hat/Fedora; Mageia; and Debian/Ubuntu. The old path (/usr/com) isn't recognized by FHS, whereas /var/lib is recognized as suitable for this purpose. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Cristian Rodríguez

19:48

El 04-10-2017 a las 10:17, Thorsten Kukuk escribió:

...

The RPM database is as static as any other file in /usr. It is only modified, if you modify files in /usr. It is not modified, if you modify files in /etc. So according to your own argumentation, the rpmdb should be in /usr.

Oook.. got it. though I do not particulary like this location, I have no objection to this argument or the idea or moving the database to /usr/something. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Antonio Larrosa

5 Oct 5 Oct

15:08

On 10/04/2017 02:59 PM, Dominique Leuenberger / DimStar wrote:

...

On Wed, 2017-10-04 at 14:37 +0200, Marcus Rueckert wrote:

...
tbh ... /etc/rpm/db would be a path i could live with ... /usr/share/rpm feels wrong to me. this is a path where i would expect static data.

/etc feels wrong in different ways: the rpm db is not any file we expect an admin to go fiddle and change content of it

Most correct would likely be /usr/lib/something - but what is the benefit over /usr/share (except improved feeling) compared to being able to share patchwork with another distro?

The way I see it, /usr/lib is for code (according to the FHS, "object files and libraries") and /usr/share is for data ("architecture independent data files"). So it makes more sense that a database is stored under /usr/share, just as /usr/share/mime/mime.cache and probably others. Also it has the side-benefit that we would use the same location than RedHat. So, another vote for /usr/share . -- Antonio Larrosa -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Frederic Crozat

4 Oct 4 Oct

13:06

Le mercredi 04 octobre 2017 à 14:37 +0200, Marcus Rueckert a écrit :

...

tbh ... /etc/rpm/db would be a path i could live with ... /usr/share/rpm feels wrong to me. this is a path where i would expect static data.

OTOH, most of the files installed in /usr/share/ are handled by rpm, which aren't that static, as soon as you update a package. Moreover, we already have some generated db in /usr (desktop applications and mime database ). -- Frederic Crozat Enterprise Desktop Release Manager SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Andreas Schwab

12:51

New subject: [opensuse-factory] Re: RFC: Proposed relocation of /var/lib/rpm

On Okt 04 2017, Richard Brown wrote:

...

Red Hat had a similar problem with their rpm-ostree tooling, which they solved by relocating the RPM database to /usr/share/rpm

Why did they choose /usr/share/rpm instead of somewhere below /usr/lib? Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Daniel Morris

14:11

New subject: [opensuse-factory] Re: RFC: Proposed relocation of /var/lib/rpm

On Wed, Oct 04, 2017 at 02:51:01PM +0200, Andreas Schwab wrote:

...

On Okt 04 2017, Richard Brown wrote:

...
Red Hat had a similar problem with their rpm-ostree tooling, which they solved by relocating the RPM database to /usr/share/rpm

Why did they choose /usr/share/rpm instead of somewhere below /usr/lib?

And will it make it into FHS 3.1, or has everyone given up on the notion of the LSB? http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.pdf Daniel -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Thorsten Kukuk

14:27

New subject: [opensuse-factory] Re: RFC: Proposed relocation of /var/lib/rpm

On Wed, Oct 04, Daniel Morris wrote:

...

On Wed, Oct 04, 2017 at 02:51:01PM +0200, Andreas Schwab wrote:

...
On Okt 04 2017, Richard Brown wrote:

...
Red Hat had a similar problem with their rpm-ostree tooling, which they solved by relocating the RPM database to /usr/share/rpm

Why did they choose /usr/share/rpm instead of somewhere below /usr/lib?

And will it make it into FHS 3.1, or has everyone given up on the notion of the LSB?

LSB is dead. There will be no new LSB version anymore. For a very long time, LSB was even completly removed from the linuxfoundation web sites. I doubt that there will ever be a new FHS version, too. Beside that /usr/share/rpm is ok according to FHS 3.0, no change of FHS is needed. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Jan Engelhardt

14:33

New subject: [opensuse-factory] Re: RFC: Proposed relocation of /var/lib/rpm

On Wednesday 2017-10-04 16:27, Thorsten Kukuk wrote:

...

...
And will it make it into FHS 3.1, or has everyone given up on the notion of the LSB?

LSB is dead. There will be no new LSB version anymore. I doubt that there will ever be a new FHS version, too.

It may not be called FHS. It just takes someone to post something like a standard. And it looks like systemd has been active in that area, having given the world new paths (with justification) and continuing to do so. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Josef Reidinger

12:51

Hi, sorry for top posting, but it is general feedback not specific to any part of of email and pasting it in bottom is easy to overlook. 1. /usr/share/ sounds bad for me, as it can be often read-only FS ( e.g. on my system it is ). 2. this snapshot and rollback make assumption that data in /var/lib is version agnostic. Can you please specify on which data you make such assumption? I think this is simply not true and just because we do not run it long enough we do not face problems. But e.g. consider that mysql as part of update migrate /var/lib/mysql to more efficient binary format and then you do rollback. Bum! And e.g. with pgsql it is even more true, as it contain also part of configuration. On my system is 62 entries in /var/lib and I am not sure if every survive bigger downgrade of software that is using it. According to this I suggest to instead move version agnostic data that should not be snapshotted to own directory for which it is clear its purpose and have such guarantie. Josef On Wed, 4 Oct 2017 13:16:58 +0200 Richard Brown wrote:

...

Hi all,

Currently, rpm stores its rpmdb (the record of all a systems packages) in /var/lib/rpm

Various openSUSE & SUSE distributions have a number of problems with this

This has a major impact on our default btrfs snapshot & rollback feature. We need the contents of the rpmdb contained within the snapshots.

This means /var/lib/rpm must be contained in the root snapshot in order to preserve the "system-state"; Without it a rolled-back system still thinks it has packages installed/removed which were changed as a result of the rollback.

But /var and /var/lib both contain a great deal of data which we DO NOT want to include in the root snapshot; For example, we most certainly don't want snapper rolling back a database in /var/lib/mysql for example, and destroying user data in the process.

Therefore we currently carry a rather complicated default list of subvolumes: https://en.opensuse.org/SDB:BTRFS#Default_Subvolumes

This list contains a number of specific directories in /var/* we wish to preserve, which means it's almost continually out of date, leading to user data being at risk if we haven't made a specific subvolume for that data.

The rpmdb is the only "system-state" information we have in /var which we need to preserve, making it quite a disruptive presence in the /var filesystem hierarchy.

The problem is further complicated in *SUSE distributions that use a Read-Only root filesystem (eg. openSUSE Kubic & SUSE CaaS Platform) because it results in a situation where we really need to micromanage countless subvolumes under /var - any location we miss otherwise ends up read-only and packages can't write to the files they expect to be able to in /var

Red Hat had a similar problem with their rpm-ostree tooling, which they solved by relocating the RPM database to /usr/share/rpm

https://rpm-ostree.readthedocs.io/en/latest/#why-not-implement-these-changes...

I would like to propose we adopt the same location for rpmdb in all *SUSE distributions

This would mean we could make a single /var subvolume and dramatically simplify our btrfs configuration

For systems with a read-only rootfs, /usr/share/rpm would be immutable and pristine, just as we require it to be. Our tooling should already be able to handle the new location without any major issues.

For systems with a read-write rootfs, we will be slightly bending the rules of the FHS, in the sense that the FHS claims /usr should be 'read-only data'

http://www.pathname.com/fhs/pub/fhs-2.3.html#THEUSRHIERARCHY

However, installing packages routinely modifies the contents of /usr and it's various subdirectories, that is the nature of installing packages.

Therefore it seems logical to me that the record of what is installed is also stored under the same conditions.

I'm working on a patchset in an OBS home project to test this proposal and shake loose any issues, and will also be proposing this location change to rpm upstream.

Therefore any comments are not only welcome, but the quicker the better, so I can factor them into what I'm doing.

I would also like suggestions as how best to handle the migration of an existing rpmdb in /var/lib/rpm to it's new location in /usr/share/rpm, as I'm certain this is something we want to get absolutely perfect, and I'm understandably nervous about changing the rpmdb's location during an rpm transaction which will be altering the rpmdb.

Thanks in advance,

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Thorsten Kukuk

13:24

On Wed, Oct 04, Josef Reidinger wrote:

...

Hi,

sorry for top posting, but it is general feedback not specific to any part of of email and pasting it in bottom is easy to overlook.

1. /usr/share/ sounds bad for me, as it can be often read-only FS ( e.g. on my system it is ).

Which means you have an problem if you update man-pages anyways.

...

2. this snapshot and rollback make assumption that data in /var/lib is version agnostic. Can you please specify on which data you make such assumption? I think this is simply not true and just because we do not run it long enough we do not face problems. But e.g. consider that mysql as part of update migrate /var/lib/mysql to more efficient binary format and then you do rollback. Bum! And e.g. with pgsql it is even more true, as it contain also part of configuration. On my system is 62 entries in /var/lib and I am not sure if every survive bigger downgrade of software that is using it.

Correct, most software is not able to handle such a version downgrade itself. But only think about a customer, who runs a mariadb based web shop and is doing a rollback. Yes, the old mariadb cannot access the data, but if you would rollback the database, the last orders would be lost. So the whole idea behind the design is, to never loose important customer data during a rollback. Thorsten

...

According to this I suggest to instead move version agnostic data that should not be snapshotted to own directory for which it is clear its purpose and have such guarantie.

Josef

On Wed, 4 Oct 2017 13:16:58 +0200 Richard Brown wrote:

...
Hi all,

Currently, rpm stores its rpmdb (the record of all a systems packages) in /var/lib/rpm

Various openSUSE & SUSE distributions have a number of problems with this

This has a major impact on our default btrfs snapshot & rollback feature. We need the contents of the rpmdb contained within the snapshots.

This means /var/lib/rpm must be contained in the root snapshot in order to preserve the "system-state"; Without it a rolled-back system still thinks it has packages installed/removed which were changed as a result of the rollback.

But /var and /var/lib both contain a great deal of data which we DO NOT want to include in the root snapshot; For example, we most certainly don't want snapper rolling back a database in /var/lib/mysql for example, and destroying user data in the process.

Therefore we currently carry a rather complicated default list of subvolumes: https://en.opensuse.org/SDB:BTRFS#Default_Subvolumes

This list contains a number of specific directories in /var/* we wish to preserve, which means it's almost continually out of date, leading to user data being at risk if we haven't made a specific subvolume for that data.

The rpmdb is the only "system-state" information we have in /var which we need to preserve, making it quite a disruptive presence in the /var filesystem hierarchy.

The problem is further complicated in *SUSE distributions that use a Read-Only root filesystem (eg. openSUSE Kubic & SUSE CaaS Platform) because it results in a situation where we really need to micromanage countless subvolumes under /var - any location we miss otherwise ends up read-only and packages can't write to the files they expect to be able to in /var

Red Hat had a similar problem with their rpm-ostree tooling, which they solved by relocating the RPM database to /usr/share/rpm

https://rpm-ostree.readthedocs.io/en/latest/#why-not-implement-these-changes...

I would like to propose we adopt the same location for rpmdb in all *SUSE distributions

This would mean we could make a single /var subvolume and dramatically simplify our btrfs configuration

For systems with a read-only rootfs, /usr/share/rpm would be immutable and pristine, just as we require it to be. Our tooling should already be able to handle the new location without any major issues.

For systems with a read-write rootfs, we will be slightly bending the rules of the FHS, in the sense that the FHS claims /usr should be 'read-only data'

http://www.pathname.com/fhs/pub/fhs-2.3.html#THEUSRHIERARCHY

However, installing packages routinely modifies the contents of /usr and it's various subdirectories, that is the nature of installing packages.

Therefore it seems logical to me that the record of what is installed is also stored under the same conditions.

I'm working on a patchset in an OBS home project to test this proposal and shake loose any issues, and will also be proposing this location change to rpm upstream.

Therefore any comments are not only welcome, but the quicker the better, so I can factor them into what I'm doing.

I would also like suggestions as how best to handle the migration of an existing rpmdb in /var/lib/rpm to it's new location in /usr/share/rpm, as I'm certain this is something we want to get absolutely perfect, and I'm understandably nervous about changing the rpmdb's location during an rpm transaction which will be altering the rpmdb.

Thanks in advance,

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Mathias Homann

14:49

Hi, Call me stupid, but why do we absolutely have to have btrfs? I mean I really do not know enough about what BTRFS can do and what it can't do to have any well funded opinion on that matter... but from following the mailing lists I am getting the feeling that one of the biggest "features" of btrfs is that it runs out of space quickly (snapshots) when people get lots of updates often (TW, Plasma, Gnome from OBS). I do believe that "we are not Red Hat" wouldn't really be the best reason. Cheers, Mathias Am 04.10.2017 um 13:16 schrieb Richard Brown:

...

Hi all,

Currently, rpm stores its rpmdb (the record of all a systems packages) in /var/lib/rpm

Various openSUSE & SUSE distributions have a number of problems with this

This has a major impact on our default btrfs snapshot & rollback feature. We need the contents of the rpmdb contained within the snapshots.

This means /var/lib/rpm must be contained in the root snapshot in order to preserve the "system-state"; Without it a rolled-back system still thinks it has packages installed/removed which were changed as a result of the rollback.

But /var and /var/lib both contain a great deal of data which we DO NOT want to include in the root snapshot; For example, we most certainly don't want snapper rolling back a database in /var/lib/mysql for example, and destroying user data in the process.

Therefore we currently carry a rather complicated default list of subvolumes: https://en.opensuse.org/SDB:BTRFS#Default_Subvolumes

This list contains a number of specific directories in /var/* we wish to preserve, which means it's almost continually out of date, leading to user data being at risk if we haven't made a specific subvolume for that data.

The rpmdb is the only "system-state" information we have in /var which we need to preserve, making it quite a disruptive presence in the /var filesystem hierarchy.

The problem is further complicated in *SUSE distributions that use a Read-Only root filesystem (eg. openSUSE Kubic & SUSE CaaS Platform) because it results in a situation where we really need to micromanage countless subvolumes under /var - any location we miss otherwise ends up read-only and packages can't write to the files they expect to be able to in /var

Red Hat had a similar problem with their rpm-ostree tooling, which they solved by relocating the RPM database to /usr/share/rpm

https://rpm-ostree.readthedocs.io/en/latest/#why-not-implement-these-changes...

I would like to propose we adopt the same location for rpmdb in all *SUSE distributions

This would mean we could make a single /var subvolume and dramatically simplify our btrfs configuration

For systems with a read-only rootfs, /usr/share/rpm would be immutable and pristine, just as we require it to be. Our tooling should already be able to handle the new location without any major issues.

For systems with a read-write rootfs, we will be slightly bending the rules of the FHS, in the sense that the FHS claims /usr should be 'read-only data'

http://www.pathname.com/fhs/pub/fhs-2.3.html#THEUSRHIERARCHY

However, installing packages routinely modifies the contents of /usr and it's various subdirectories, that is the nature of installing packages.

Therefore it seems logical to me that the record of what is installed is also stored under the same conditions.

I'm working on a patchset in an OBS home project to test this proposal and shake loose any issues, and will also be proposing this location change to rpm upstream.

Therefore any comments are not only welcome, but the quicker the better, so I can factor them into what I'm doing.

I would also like suggestions as how best to handle the migration of an existing rpmdb in /var/lib/rpm to it's new location in /usr/share/rpm, as I'm certain this is something we want to get absolutely perfect, and I'm understandably nervous about changing the rpmdb's location during an rpm transaction which will be altering the rpmdb.

Thanks in advance,

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Thorsten Kukuk

15:05

On Wed, Oct 04, Mathias Homann wrote:

...

Hi,

Call me stupid, but why do we absolutely have to have btrfs?

We don't need to have btrfs, it's your choice to use it or not. But there is no other CoW filesystem with all necessary features available for Linux today. But every other solution for snaphot and rollback has the same problems.

...

I mean I really do not know enough about what BTRFS can do and what it can't do to have any well funded opinion on that matter... but from following the mailing lists I am getting the feeling that one of the biggest "features" of btrfs is that it runs out of space quickly (snapshots) when people get lots of updates often (TW, Plasma, Gnome from OBS).

That's pretty old stuff and in most cases this is coming from a wrong setup (like people updating from openSUSE 13.x and having a wrong filesystem layout). Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Bruno Friedmann

15:21

On mercredi, 4 octobre 2017 17.05:02 h CEST Thorsten Kukuk wrote:

...

On Wed, Oct 04, Mathias Homann wrote:

...
Hi,

Call me stupid, but why do we absolutely have to have btrfs?

We don't need to have btrfs, it's your choice to use it or not. But there is no other CoW filesystem with all necessary features available for Linux today.

But every other solution for snaphot and rollback has the same problems.

...
I mean I really do not know enough about what BTRFS can do and what it can't do to have any well funded opinion on that matter... but from following the mailing lists I am getting the feeling that one of the biggest "features" of btrfs is that it runs out of space quickly (snapshots) when people get lots of updates often (TW, Plasma, Gnome from OBS).

That's pretty old stuff and in most cases this is coming from a wrong setup (like people updating from openSUSE 13.x and having a wrong filesystem layout).

Thorsten Last paragraph avoiding would I ;-)

[oct 1 19:52] ------------[ cut here ]------------ [ +0.000031] WARNING: CPU: 4 PID: 417 at ../fs/btrfs/qgroup.c:2466 btrfs_qgroup_free_refroot+0x154/0x180 [btrfs]() [ +0.000003] Modules linked in: vhost_net vhost macvtap macvlan tun ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter ip_tables x_tables fuse af_packet dm_mod br_netfilter bridge stp llc iscsi_ibft iscsi_boot_sysfs it87 hwmon_vid msr xfs libcrc32c kvm_amd kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel drbg amdkfd amd_iommu_v2 snd_hda_codec_realtek radeon ansi_cprng raid10 snd_hda_codec_generic ttm snd_hda_codec_hdmi drm_kms_helper snd_hda_intel snd_hda_codec drm eeepc_wmi snd_hda_core aesni_intel asus_wmi snd_hwdep fb_sys_fops sparse_keymap snd_pcm e1000e syscopyarea rfkill aes_x86_64 lrw snd_timer gf128mul glue_helper ablk_helper sysfillrect sysimgblt snd video mxm_wmi pcspkr i2c_algo_bit edac_mce_amd soundcore sp5100_tco cryptd fam15h_power ptp k10temp edac_core [ +0.000062] pps_core [ +0.000001] i2c_piix4 tpm_infineon wmi fjes button processor shpchp btrfs xor raid6_pq raid1 md_mod sd_mod hid_generic usbhid ohci_pci crc32c_intel xhci_pci ohci_hcd ehci_pci ahci xhci_hcd ehci_hcd libahci libata usbcore usb_common sg scsi_mod autofs4 [ +0.000024] CPU: 4 PID: 417 Comm: btrfs-transacti Tainted: G W 4.4.87-25-default #1 [ +0.000002] Hardware name: To be filled by O.E.M. To be filled by O.E.M./ CROSSHAIR V FORMULA-Z, BIOS 2201 03/23/2015 [ +0.000001] 0000000000000000 ffffffff81339eb7 0000000000000000 ffffffffa03e8b75 [ +0.000004] ffffffff81080681 [ +0.000001] ffff88080b4879c8 00000000021b8000 ffff880809fe0d80 [ +0.000003] ffff88080b487940 [ +0.000001] ffff880809fe0000 [ +0.000003] ffffffffa03d00c4 0000000000000103 [ +0.000000] Call Trace: [ +0.000010] [<ffffffff81019f29>] dump_trace+0x59/0x320 [ +0.000004] [<ffffffff8101a2ea>] show_stack_log_lvl+0xfa/0x180 [ +0.000002] [<ffffffff8101b091>] show_stack+0x21/0x40 [ +0.000003] [<ffffffff81339eb7>] dump_stack+0x5c/0x85 [ +0.000003] [<ffffffff81080681>] warn_slowpath_common+0x81/0xb0 [ +0.000016] [<ffffffffa03d00c4>] btrfs_qgroup_free_refroot+0x154/0x180 [btrfs] [ +0.000018] [<ffffffffa035f4fe>] commit_fs_roots.isra.20+0x14e/0x190 [btrfs] [ +0.000014] [<ffffffffa0361e88>] btrfs_commit_transaction.part. 26+0x498/0xad0 [btrfs] [ +0.000013] [<ffffffffa035c1cb>] transaction_kthread+0x21b/0x280 [btrfs] [ +0.000004] [<ffffffff8109f412>] kthread+0xd2/0xf0 [ +0.000005] [<ffffffff8163180f>] ret_from_fork+0x3f/0x70 [ +0.001217] DWARF2 unwinder stuck at ret_from_fork+0x3f/0x70 [ +0.000001] Leftover inexact backtrace: [ +0.000003] [<ffffffff8109f340>] ? kthread_park+0x50/0x50 [ +0.000002] ---[ end trace 38e96950a80cd2b9 ]--- [ +0.000002] BTRFS warning (device md1): qgroup 259 reserved space underflow, have: 35352576, to free: 35356672 [oct 2 10:26] BTRFS info (device md1): found 1793 extents [ +23.464622] BTRFS info (device md1): found 15 extents [ +15.925296] BTRFS info (device md1): 1 enospc errors during balance [oct 3 10:16] BTRFS info (device md1): qgroup scan completed (inconsistency flag cleared) [oct 4 10:17] BTRFS info (device md1): qgroup scan completed (inconsistency flag cleared) openSUSE Leap 42.3, default proposed install, last kernel and update installed ;-) Yeap still missing the boo# id (I need to filter existing one) -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch Bareos Partner, openSUSE Member, fsfe fellowship GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Ludwig Nussel

15:04

Richard Brown wrote:

...

Currently, rpm stores its rpmdb (the record of all a systems packages) in /var/lib/rpm

Various openSUSE & SUSE distributions have a number of problems with this

This has a major impact on our default btrfs snapshot & rollback feature. We need the contents of the rpmdb contained within the snapshots. [...] Red Hat had a similar problem with their rpm-ostree tooling, which they solved by relocating the RPM database to /usr/share/rpm

Even though preferring share/ over lib/ feels counter intuitive to me I think it's a detail. The overall idea to move the rpm database to /usr makes a lot of sense. Nowadays /usr is meant to contain basically of all of the operating system. So the manifest of what constitutes the operating system fits there too. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Dave Plater

15:19

On 04/10/2017 13:16, Richard Brown wrote:

...

Hi all,

Currently, rpm stores its rpmdb (the record of all a systems packages) in /var/lib/rpm

Various openSUSE & SUSE distributions have a number of problems with this

This has a major impact on our default btrfs snapshot & rollback feature. We need the contents of the rpmdb contained within the snapshots.

This means /var/lib/rpm must be contained in the root snapshot in order to preserve the "system-state"; Without it a rolled-back system still thinks it has packages installed/removed which were changed as a result of the rollback.

But /var and /var/lib both contain a great deal of data which we DO NOT want to include in the root snapshot; For example, we most certainly don't want snapper rolling back a database in /var/lib/mysql for example, and destroying user data in the process.

Therefore we currently carry a rather complicated default list of subvolumes: https://en.opensuse.org/SDB:BTRFS#Default_Subvolumes

This list contains a number of specific directories in /var/* we wish to preserve, which means it's almost continually out of date, leading to user data being at risk if we haven't made a specific subvolume for that data.

The rpmdb is the only "system-state" information we have in /var which we need to preserve, making it quite a disruptive presence in the /var filesystem hierarchy.

The problem is further complicated in *SUSE distributions that use a Read-Only root filesystem (eg. openSUSE Kubic & SUSE CaaS Platform) because it results in a situation where we really need to micromanage countless subvolumes under /var - any location we miss otherwise ends up read-only and packages can't write to the files they expect to be able to in /var

Red Hat had a similar problem with their rpm-ostree tooling, which they solved by relocating the RPM database to /usr/share/rpm

https://rpm-ostree.readthedocs.io/en/latest/#why-not-implement-these-changes...

I would like to propose we adopt the same location for rpmdb in all *SUSE distributions

This would mean we could make a single /var subvolume and dramatically simplify our btrfs configuration

For systems with a read-only rootfs, /usr/share/rpm would be immutable and pristine, just as we require it to be. Our tooling should already be able to handle the new location without any major issues.

For systems with a read-write rootfs, we will be slightly bending the rules of the FHS, in the sense that the FHS claims /usr should be 'read-only data'

http://www.pathname.com/fhs/pub/fhs-2.3.html#THEUSRHIERARCHY

However, installing packages routinely modifies the contents of /usr and it's various subdirectories, that is the nature of installing packages.

Therefore it seems logical to me that the record of what is installed is also stored under the same conditions.

I'm working on a patchset in an OBS home project to test this proposal and shake loose any issues, and will also be proposing this location change to rpm upstream.

Therefore any comments are not only welcome, but the quicker the better, so I can factor them into what I'm doing.

I would also like suggestions as how best to handle the migration of an existing rpmdb in /var/lib/rpm to it's new location in /usr/share/rpm, as I'm certain this is something we want to get absolutely perfect, and I'm understandably nervous about changing the rpmdb's location during an rpm transaction which will be altering the rpmdb.

Thanks in advance,

You need to start a new thread for the last and most important part of your message. My personal opinion is /usr/lib/rpm /usr/share is overpopulated with directories. Dave P -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Anton Aylward

15:27

On 04/10/17 11:19 AM, Dave Plater wrote:

...

My personal opinion is /usr/lib/rpm /usr/share is overpopulated with directories.

That's a very good observation and good justification for not using /usr/share. Thank you. You've convinced me. -- Capitalism is the astounding belief that the most wickedest of men will do the most wickedest of things for the greatest good of everyone. --John Maynard Keynes -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Michal Kubecek

5 Oct 5 Oct

05:18

On Wednesday, 4 October 2017 17:19 Dave Plater wrote:

...

You need to start a new thread for the last and most important part of your message. My personal opinion is /usr/lib/rpm /usr/share is overpopulated with directories.

That's really weak argument, I must say. As I'm not one of those who believe that all old standards are dead and 0pointer.de is the word of God, let's check what FHS says: /usr/share: Architecture-independent data So the question we should ask is: is the format of RPM database architecture independent? If it is, /usr/share is fine, if not, I would adwise strongly against it and prefer /usr/lib. Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Dave Plater

05:37

On 05/10/2017 07:18, Michal Kubecek wrote:

...

On Wednesday, 4 October 2017 17:19 Dave Plater wrote:

...
You need to start a new thread for the last and most important part of your message. My personal opinion is /usr/lib/rpm /usr/share is overpopulated with directories.

That's really weak argument, I must say.

As I'm not one of those who believe that all old standards are dead and 0pointer.de is the word of God, let's check what FHS says:

/usr/share: Architecture-independent data

So the question we should ask is: is the format of RPM database architecture independent? If it is, /usr/share is fine, if not, I would adwise strongly against it and prefer /usr/lib.

Michal Kubeček

I think that the architecture argument doesn't work for /usr/lib, one example is %python_sitelib - site-packages directory for platform-independent modules. Expands to /usr/lib/python%{py_ver}/site-packages Not to mention the fact that /usr/lib/rpm contains most of rpm's architecture independent files. It also contains the only text reference to /var/lib/rpm in rpmdb_loadcvt. Dave P -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Michal Kubecek

05:44

On Thursday, 5 October 2017 7:37 Dave Plater wrote:

...

On 05/10/2017 07:18, Michal Kubecek wrote:

...
On Wednesday, 4 October 2017 17:19 Dave Plater wrote:

...
You need to start a new thread for the last and most important part of your message. My personal opinion is /usr/lib/rpm /usr/share is overpopulated with directories.

That's really weak argument, I must say.

As I'm not one of those who believe that all old standards are dead and> 0pointer.de is the word of God, let's check what FHS says: /usr/share: Architecture-independent data

So the question we should ask is: is the format of RPM database architecture independent? If it is, /usr/share is fine, if not, I would adwise strongly against it and prefer /usr/lib.

Michal Kubeček

I think that the architecture argument doesn't work for /usr/lib, one example is %python_sitelib - site-packages directory for platform-independent modules. Expands to /usr/lib/python%{py_ver}/site-packages Not to mention the fact that /usr/lib/rpm contains most of rpm's architecture independent files. It also contains the only text reference to /var/lib/rpm in rpmdb_loadcvt.

It does work in the opposite direction, though: if the files are architecture dependent, they do not belong under /usr/share Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Jan Engelhardt

10:27

On Thursday 2017-10-05 07:44, Michal Kubecek wrote:

...

It does work in the opposite direction, though: if the files are architecture dependent, they do not belong under /usr/share

Depends on what you define as "architecture-(in)dependent". We put .wav files into /usr/share and $game is - save for bugs - able to read these Little Endian-specific files all the time. rpm surely behaves similar. By that measure alone, the rpmdb would be arch-indep. The other measure is "paths listed in any such data file". If something contains /usr/lib64 in it (or more visibly, /usr/lib/x86_64-linux-gnu on Debian), then that cannot be arch-independent. Or is it - because every program is able to read the file? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Achim Gratz

4 Oct 4 Oct

17:23

New subject: [opensuse-factory] Re: RFC: Proposed relocation of /var/lib/rpm

Richard Brown writes:

...

Red Hat had a similar problem with their rpm-ostree tooling, which they solved by relocating the RPM database to /usr/share/rpm

https://rpm-ostree.readthedocs.io/en/latest/#why-not-implement-these-changes...

I would like to propose we adopt the same location for rpmdb in all *SUSE distributions

Following a precedent might be a good idea, but /usr/share/rpm just feels wrong. I think /usr/share should contain only architecture independent data and the rpm database for any concrete installation just isn't. Another option would be /usr/lib/rpm (which already exists and is quite crowded), but I personally would rather go for a new directory branch along the lines of /usr/sys/rpm or /usr/inst/rpm (rpm might not be the only thing that has that problem). Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

C. R. Oldham

17:47

New subject: [opensuse-factory] Re: RFC: Proposed relocation of /var/lib/rpm

So why not simply /usr/rpm? --cro -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Jiri Slaby

5 Oct 5 Oct

06:39

New subject: [opensuse-factory] Re: RFC: Proposed relocation of /var/lib/rpm

On 10/04/2017, 07:23 PM, Achim Gratz wrote:

...

Richard Brown writes:

...
Red Hat had a similar problem with their rpm-ostree tooling, which they solved by relocating the RPM database to /usr/share/rpm

https://rpm-ostree.readthedocs.io/en/latest/#why-not-implement-these-changes...

I would like to propose we adopt the same location for rpmdb in all *SUSE distributions

Following a precedent might be a good idea, but /usr/share/rpm just feels wrong. I think /usr/share should contain only architecture independent data and the rpm database for any concrete installation just isn't.

Are you so sure? This machine was running fedora i386 (cloned from another machine's HDD via dd), fedora i586, fedora 64-bit and for quite some time opensuse 64-bit too. Still with the original "i386" rpmdb. I never reinstalled in the past decade. So I really do not share your point. thanks, -- js suse labs -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Richard Brown

07:47

New subject: [opensuse-factory] Re: RFC: Proposed relocation of /var/lib/rpm

Thanks everyone for the feedback so far The vast majority of feedback seems to not object to the idea of moving the rpmdb out of /var, but there is obviously a fair bit of concern that /usr/share is not the correct place for it We don't want to 'double book' /usr/lib/rpm which is already in use by rpm, but I can definitely see the logic of having it in /usr/lib Therefore my proposal now is that we'll use /usr/lib/rpmdb as the new location for the rpmdb location, and I'm changing my patchset accordingly. Thanks On 5 October 2017 at 08:39, Jiri Slaby wrote:

...

On 10/04/2017, 07:23 PM, Achim Gratz wrote:

...
Richard Brown writes:

...
Red Hat had a similar problem with their rpm-ostree tooling, which they solved by relocating the RPM database to /usr/share/rpm

https://rpm-ostree.readthedocs.io/en/latest/#why-not-implement-these-changes...

I would like to propose we adopt the same location for rpmdb in all *SUSE distributions

Following a precedent might be a good idea, but /usr/share/rpm just feels wrong. I think /usr/share should contain only architecture independent data and the rpm database for any concrete installation just isn't.

Are you so sure? This machine was running fedora i386 (cloned from another machine's HDD via dd), fedora i586, fedora 64-bit and for quite some time opensuse 64-bit too. Still with the original "i386" rpmdb. I never reinstalled in the past decade. So I really do not share your point.

thanks, -- js suse labs -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Michael Aquilina

09:07

New subject: [opensuse-factory] Re: RFC: Proposed relocation of /var/lib/rpm

Excuse my ignorance on this topic, but how would this proposal affect /var/lib/docker? Currently rollbacks on btrfs cause docker to end up in an inconsistent state and the only solution is completely remove /var/lib/docker and setting up your containers all over again. I've posted on this mailing list before about this issue and the proposed solution was to move /var/lib/docker to its own partition or subvolume. Would moving /var/lib/rpmdb out and making /var/lib its own subvolume solve this docker rollback problem? Mike On Thu, Oct 5, 2017 at 8:47 AM, Richard Brown wrote:

...

Thanks everyone for the feedback so far

The vast majority of feedback seems to not object to the idea of moving the rpmdb out of /var, but there is obviously a fair bit of concern that /usr/share is not the correct place for it

We don't want to 'double book' /usr/lib/rpm which is already in use by rpm, but I can definitely see the logic of having it in /usr/lib

Therefore my proposal now is that we'll use /usr/lib/rpmdb as the new location for the rpmdb location, and I'm changing my patchset accordingly.

Thanks

On 5 October 2017 at 08:39, Jiri Slaby wrote:

...
On 10/04/2017, 07:23 PM, Achim Gratz wrote:

...
Richard Brown writes:

...
Red Hat had a similar problem with their rpm-ostree tooling, which they solved by relocating the RPM database to /usr/share/rpm

https://rpm-ostree.readthedocs.io/en/latest/#why-not-implement-these-changes...

I would like to propose we adopt the same location for rpmdb in all *SUSE distributions

Following a precedent might be a good idea, but /usr/share/rpm just feels wrong. I think /usr/share should contain only architecture independent data and the rpm database for any concrete installation just isn't.

Are you so sure? This machine was running fedora i386 (cloned from another machine's HDD via dd), fedora i586, fedora 64-bit and for quite some time opensuse 64-bit too. Still with the original "i386" rpmdb. I never reinstalled in the past decade. So I really do not share your point.

thanks, -- js suse labs -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-- Michael Aquilina -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Richard Brown

09:14

New subject: [opensuse-factory] Re: RFC: Proposed relocation of /var/lib/rpm

On 5 October 2017 at 11:07, Michael Aquilina wrote:

...

Excuse my ignorance on this topic, but how would this proposal affect /var/lib/docker?

Currently rollbacks on btrfs cause docker to end up in an inconsistent state and the only solution is completely remove /var/lib/docker and setting up your containers all over again. I've posted on this mailing list before about this issue and the proposed solution was to move /var/lib/docker to its own partition or subvolume.

Would moving /var/lib/rpmdb out and making /var/lib its own subvolume solve this docker rollback problem?

Yup, it would. That said, it's still best practice (for performance reasons) to make a separate btrfs partition for /var/lib/docker - that's what we do in CaaSP & Kubic. But at least we wont be putting your data at risk when you don't do that, where as right now, yeah, it's less than ideal, and hard for us to manage when introducing any new package that stores the data we don't want it to touch in /var -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Manfred Hollstein

13:42

Hi there, On Thu, 05 Oct 2017, 09:47:25 +0200, Richard Brown wrote:

...

Thanks everyone for the feedback so far

The vast majority of feedback seems to not object to the idea of moving the rpmdb out of /var, but there is obviously a fair bit of concern that /usr/share is not the correct place for it

We don't want to 'double book' /usr/lib/rpm which is already in use by rpm, but I can definitely see the logic of having it in /usr/lib

Therefore my proposal now is that we'll use /usr/lib/rpmdb as the new location for the rpmdb location, and I'm changing my patchset accordingly.

I look at this topic from a completely different angle (though it might be related to the view of btrfs maintainers/users caring for how the file system is structured): I always put /var on a separate partition, nowadays living on a rotating disk (actually two disks combined into one raid1) to ensure the ssd hosting the root file system doesn't get written to too frequently. While I can bind-mount any directory from /usr to the rotating disk, I agree with other posters that /usr doesn't sound right. I admit this doesn't help at all with the snapshot/rollback issue, though. Nevertheless, I thought this point of view might help with the whole discussion, too.

...

Thanks

Cheers. l8er manfred

Dominique Leuenberger / DimStar

13:47

On Thu, 2017-10-05 at 15:42 +0200, Manfred Hollstein wrote:

...

I look at this topic from a completely different angle (though it might be related to the view of btrfs maintainers/users caring for how the file system is structured): I always put /var on a separate partition, nowadays living on a rotating disk (actually two disks combined into one raid1) to ensure the ssd hosting the root file system doesn't get written to too frequently. While I can bind-mount any directory from /usr to the rotating disk, I agree with other posters that /usr doesn't sound right. I admit this doesn't help at all with the snapshot/rollback issue, though. Nevertheless, I thought this point of view might help with the whole discussion, too.

I don't understand you argument here: you will write the rpmdb about as often as you write other stuff to /usr anyway, as this happens when you install/update/remove packages... hence having it in /usr does not cause really a higher write load to your ssd what exactly did you try to convey? Cheers Dominique

Manfred Hollstein

14:05

On Thu, 05 Oct 2017, 15:47:39 +0200, Dominique Leuenberger / DimStar wrote:

...

On Thu, 2017-10-05 at 15:42 +0200, Manfred Hollstein wrote:

...
I look at this topic from a completely different angle (though it might be related to the view of btrfs maintainers/users caring for how the file system is structured): I always put /var on a separate partition, nowadays living on a rotating disk (actually two disks combined into one raid1) to ensure the ssd hosting the root file system doesn't get written to too frequently. While I can bind-mount any directory from /usr to the rotating disk, I agree with other posters that /usr doesn't sound right. I admit this doesn't help at all with the snapshot/rollback issue, though. Nevertheless, I thought this point of view might help with the whole discussion, too.

I don't understand you argument here: you will write the rpmdb about as often as you write other stuff to /usr anyway, as this happens when you install/update/remove packages... hence having it in /usr does not cause really a higher write load to your ssd

what exactly did you try to convey?

_avoiding the traffic to rpmdb_?!?

...

Cheers Dominique

Cheers. l8er manfred

Carlos E. R.

22:15

On 2017-10-05 16:05, Manfred Hollstein wrote:

...

On Thu, 05 Oct 2017, 15:47:39 +0200, Dominique Leuenberger / DimStar wrote:

...
On Thu, 2017-10-05 at 15:42 +0200, Manfred Hollstein wrote:

...
I look at this topic from a completely different angle (though it might be related to the view of btrfs maintainers/users caring for how the file system is structured): I always put /var on a separate partition, nowadays living on a rotating disk (actually two disks combined into one raid1) to ensure the ssd hosting the root file system doesn't get written to too frequently. While I can bind-mount any directory from /usr to the rotating disk, I agree with other posters that /usr doesn't sound right. I admit this doesn't help at all with the snapshot/rollback issue, though. Nevertheless, I thought this point of view might help with the whole discussion, too.

I don't understand you argument here: you will write the rpmdb about as often as you write other stuff to /usr anyway, as this happens when you install/update/remove packages... hence having it in /usr does not cause really a higher write load to your ssd

what exactly did you try to convey?

_avoiding the traffic to rpmdb_?!?

rpmdb benefits a lot from being on an SSD, for read. And it is not written to that often. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)

Thorsten Kukuk

6 Oct 6 Oct

05:41

On Thu, Oct 05, Manfred Hollstein wrote:

...

I look at this topic from a completely different angle (though it might be related to the view of btrfs maintainers/users caring for how the file system is structured): I always put /var on a separate partition, nowadays living on a rotating disk (actually two disks combined into one raid1) to ensure the ssd hosting the root file system doesn't get written to too frequently.

I know, every cheap computer magazine is telling you, that you have to avoid writing to SSDs, but that's only true for cheap SSDs. If you don't have a really cheap SSD, it's very unlikely that you will see the end-of-life of your SSD during your life by only updating /usr including the rpmdb. Most likely you will buy a newer one because your current one will be too small. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Neal Gompa

9 Oct 9 Oct

13:36

New subject: [opensuse-factory] Re: RFC: Proposed relocation of /var/lib/rpm

On Thu, Oct 5, 2017 at 3:47 AM, Richard Brown wrote:

...

Thanks everyone for the feedback so far

The vast majority of feedback seems to not object to the idea of moving the rpmdb out of /var, but there is obviously a fair bit of concern that /usr/share is not the correct place for it

We don't want to 'double book' /usr/lib/rpm which is already in use by rpm, but I can definitely see the logic of having it in /usr/lib

Therefore my proposal now is that we'll use /usr/lib/rpmdb as the new location for the rpmdb location, and I'm changing my patchset accordingly.

Speaking as someone who often has to integrate with rpm and introspect things like rpmdb, I don't particularly love the idea of yet another path for where it could be. Frankly, I get why you want this. I've rolled my own btrfs setups for about two years now on Fedora, and I can easily understand why you want to relocate the rpmdb to simplify the mess that is /var subvolumes. That said, I'd rather see us use a common alternate path. Currently that is /usr/share/rpm, which I don't love because it makes things really annoying for some of the work I'm doing. I don't mind /usr/lib/rpmdb so much, but I would rather see this be the common alternate path used. Which means, I'd like you to convince Colin Walters to migrate the rpmdb in RPM-OSTree / Project Atomic setups to this location *before* doing this. My reason is simple: Tools and libraries that interface with the rpmdb need to know where it is. The more places it could possibly be, the harder it is to deal with. Keep in mind, also, that rpm now has three rpmdb backends that could be used (even though libsolv is broken with two of them...). In fact, libsolv is *already* aware of /usr/share/rpm, since it directly manipulates the rpmdb. There's a lot of assumptions that you're breaking by moving the rpmdb, and because the SUSE rpmdb is on a writable filesystem, it's actually possible for it to be important. Let's not make this harder for everyone, please? -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Anton Aylward

14:38

New subject: [opensuse-factory] Re: RFC: Proposed relocation of /var/lib/rpm

On 05/10/17 03:47 AM, Richard Brown wrote:

...

Thanks everyone for the feedback so far

The vast majority of feedback seems to not object to the idea of moving the rpmdb out of /var, but there is obviously a fair bit of concern that /usr/share is not the correct place for it

We don't want to 'double book' /usr/lib/rpm which is already in use by rpm, but I can definitely see the logic of having it in /usr/lib

Therefore my proposal now is that we'll use /usr/lib/rpmdb as the new location for the rpmdb location, and I'm changing my patchset accordingly.

Thanks

Thank YOU! -- He who stops being better stops being good. -- Oliver Cromwell -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Knurpht - Gertjan Lettink

14:43

New subject: [opensuse-factory] Re: RFC: Proposed relocation of /var/lib/rpm

Op maandag 9 oktober 2017 16:38:50 CEST schreef Anton Aylward:

...

On 05/10/17 03:47 AM, Richard Brown wrote:

...
Thanks everyone for the feedback so far

The vast majority of feedback seems to not object to the idea of moving the rpmdb out of /var, but there is obviously a fair bit of concern that /usr/share is not the correct place for it

We don't want to 'double book' /usr/lib/rpm which is already in use by rpm, but I can definitely see the logic of having it in /usr/lib

Therefore my proposal now is that we'll use /usr/lib/rpmdb as the new location for the rpmdb location, and I'm changing my patchset accordingly.

Thanks

Thank YOU!

I've stayed out of this discussion for assumed lack of knowledge, but after a lot of reading /usr/lib/rpmdb seems perfect. -- Gertjan Lettink, a.k.a. Knurpht openSUSE Board Member openSUSE Forums Team -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Richard Brown

14:46

New subject: [opensuse-factory] Re: RFC: Proposed relocation of /var/lib/rpm

On 9 October 2017 at 16:38, Anton Aylward wrote:

...

On 05/10/17 03:47 AM, Richard Brown wrote:

...
Thanks everyone for the feedback so far

The vast majority of feedback seems to not object to the idea of moving the rpmdb out of /var, but there is obviously a fair bit of concern that /usr/share is not the correct place for it

We don't want to 'double book' /usr/lib/rpm which is already in use by rpm, but I can definitely see the logic of having it in /usr/lib

Therefore my proposal now is that we'll use /usr/lib/rpmdb as the new location for the rpmdb location, and I'm changing my patchset accordingly.

Thanks

Thank YOU!

Don't thank me too heavily yet - while I do have a working package (and Tumbleweed, Kubic, and SLE images) with /usr/lib/rpmdb, I am rather swayed by Neal's arguments, especially as he's an rpm contributor upstream. I'm reaching out to other rpm upstream developers and other interested parties to get a better feel for a broader feeling. This isn't the sort of thing I want to change twice ;) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Bruno Friedmann

15:11

New subject: [opensuse-factory] Re: RFC: Proposed relocation of /var/lib/rpm

On lundi, 9 octobre 2017 16.46:22 h CEST Richard Brown wrote:

...

I'm reaching out to other rpm upstream developers and other interested parties to get a better feel for a broader feeling.

Which is the right way to do it, more we have common shared things, better it is for admins of all horizons. Thanks for taking that into account.

...

This isn't the sort of thing I want to change twice Yeap sure, but you CAN :-))

-- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch Bareos Partner, openSUSE Member, fsfe fellowship GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Richard Brown

27 Oct 27 Oct

15:36

New subject: [opensuse-factory] Re: RFC: Proposed relocation of /var/lib/rpm

On 9 October 2017 at 17:11, Bruno Friedmann wrote:

...

On lundi, 9 octobre 2017 16.46:22 h CEST Richard Brown wrote:

...
I'm reaching out to other rpm upstream developers and other interested parties to get a better feel for a broader feeling.

Which is the right way to do it, more we have common shared things, better it is for admins of all horizons. Thanks for taking that into account.

...
This isn't the sort of thing I want to change twice Yeap sure, but you CAN :-))

After discussions with rpm upstream, the consensus is now that the suitable location is /usr/lib/sysimage/rpm /usr/lib/sysimage is a new location conceptualised to be shared for this 'class' of data - object files and other assorted data which describes the "system image". Such as rpm's database, apt's database, and potentially other similar package databases. This location should be perfectly suitable for systems with read-only filesystem usecases (eg. Kubic, RH Atomic, etc) and has the agreement of RH Atomic's rpm-ostree developer. It also is a location that solves all of our problems as a very 'snapshot orientated' distribution. I also see benefits in this location to simplify many peoples backup routines - /var should now be treatable as truly variable data, consisting of nothing needed to get the _system_ back up and running. For those backing up system and services separately, /var should now be treatable with the same logic as /srv - needed to backup your services, not your system. Along with rpm upstream, we'll be approaching other projects that have a similar problem with their use of /var suggesting the use of /usr/lib/sysimage as the solution to those using read-only filesystems, using system snapshotting, or wanting to simplify peoples backup options. Long term, rpm is considering this location as a possible future default, but with obvious work to do before - such as coming up with a migration routine that will work in every scenario and distribution where rpm is used. Meanwhile, for openSUSE I have a migration routine that I'm happy will work for all of our scenarios. Our patched rpm package with the new location is building in the appropriate Devel Project and will be sent to Factory soon. Thanks to everyone for their feedback. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

2379

Age (days ago)

2402

Last active (days ago)

List overview

Download

52 comments

27 participants

participants (27)

Achim Gratz
Andreas Schwab
Anton Aylward
Antonio Larrosa
Bruno Friedmann
C. R. Oldham
Carlos E. R.
Cristian Rodríguez
Daniel Morris
Dave Plater
Dominique Leuenberger / DimStar
Frederic Crozat
Jan Engelhardt
Jiri Slaby
Josef Reidinger
Knurpht - Gertjan Lettink
Ludwig Nussel
Manfred Hollstein
Marcus Hüwe
Marcus Rueckert
Martin Pluskal
Mathias Homann
Michael Aquilina
Michal Kubecek
Neal Gompa
Richard Brown
Thorsten Kukuk