From ngompa13 at gmail.com  Fri Dec  3 20:11:59 2021
From: ngompa13 at gmail.com (Neal Gompa)
Date: Fri, 3 Dec 2021 15:11:59 -0500
Subject: [Rpm-ecosystem] why do elf dependency generators cover
 libraries in paths outside of the library load paths?
In-Reply-To: <3df30db9-1428-d951-b4a9-99a37239e2a0@redhat.com>
References: <20211203195342.GD1503@in.waw.pl>
 <3df30db9-1428-d951-b4a9-99a37239e2a0@redhat.com>
Message-ID: <CAEg-Je-ccu6dtqRKF=-w0u-EC+RQWikhpJqBGSfsguLnbn5BGw@mail.gmail.com>

On Fri, Dec 3, 2021 at 3:10 PM Miro Hron?ok <mhroncok at redhat.com> wrote:
>
> On 03. 12. 21 20:53, Zbigniew J?drzejewski-Szmek wrote:
> > We had an incident today [1] that opae-devel has auto-generated provides
> > like libcrypto.so.1.1()(64bit), generated for the bundled copy of openssl
> > (/usr/lib/python3.10/site-packages/pacsign/hsm_managers/openssl/library/libcrypto.so).
> > It was pulled into the buildroot instead of the expected openssl1.1 package.
> > Those deps are generated by /usr/lib/rpm/elfdeps, which is configured in
> > /usr/lib/rpm/fileattrs/elf.attr to act on anything that matches the
> > file magic of '^(setuid,? )?(setgid,? )?(sticky )?ELF (32|64)-bit.*$'.
> >
> > My question: shouldn't we limit the elfdeps generator to files which
> > are in paths that can be loaded automatically by the linker? (This
> > could be implemented as e.g. the paths that are default like
> > /usr/lib64, /usr/local/lib64, ?, depending on the architecture, and if
> > the package installs anything in /etc/ld.so/, also the paths listed there.)
> >
> > I always understood those Provides/Requires to be used for library
> > dependency resolution, and it doesn't seem to make sense to generate
> > them for plugins and other "private" objects outside of the linker
> > load paths.
> >
> > I think it's much much more common to have .so libraries outside of
> > the linker paths for which we don't want the automatic provides
> > (python modules, java extensions, various loadable plugins), than to
> > have shared libraries in some custom directory. This should eliminate
> > most of the stupid issues where a "private" dependency leaks and
> > breaks other packages.
> >
> > [1] bugzilla.redhat.com/2028852
>
> As one of the Fedora's Python maintainers, I fully support the idea of only
> generating provides from "normal" library directories.
>
> We still have Python packages that accidentally provide stuff like:
>
> lib.cpython-310-x86_64-linux-gnu.so()(64bit)
> libcalignedsegment.cpython-310-x86_64-linux-gnu.so()(64bit)
> libcalignmentfile.cpython-310-x86_64-linux-gnu.so()(64bit)
> libcbcf.cpython-310-x86_64-linux-gnu.so()(64bit)
> libcbcftools.cpython-310-x86_64-linux-gnu.so()(64bit)
> libcbgzf.cpython-310-x86_64-linux-gnu.so()(64bit)
> libcfaidx.cpython-310-x86_64-linux-gnu.so()(64bit)
> libchtslib.cpython-310-x86_64-linux-gnu.so()(64bit)
> libcsamfile.cpython-310-x86_64-linux-gnu.so()(64bit)
> libcsamtools.cpython-310-x86_64-linux-gnu.so()(64bit)
> libctabix.cpython-310-x86_64-linux-gnu.so()(64bit)
> libctabixproxies.cpython-310-x86_64-linux-gnu.so()(64bit)
> libcutils.cpython-310-x86_64-linux-gnu.so()(64bit)
> libcvcf.cpython-310-x86_64-linux-gnu.so()(64bit)
> libexiv2python.cpython-310-x86_64-linux-gnu.so()(64bit)
> libguestfsmod.cpython-310-x86_64-linux-gnu.so()(64bit)
> libhivexmod.cpython-310-x86_64-linux-gnu.so()(64bit)
> libiscsi.cpython-310-x86_64-linux-gnu.so()(64bit)
> liblo.cpython-310-x86_64-linux-gnu.so()(64bit)
> libpyuhd.cpython-310-x86_64-linux-gnu.so()(64bit)
> libtorrent.cpython-310-x86_64-linux-gnu.so()(64bit)
>
> (This is actually from Fedora Rawhide, as of today.)
>

The issue is self-Requires. Because the RPM dependency generator
doesn't cancel out self-Requires, filtering out Provides leads to
broken Requires in a lot of cases.



-- 
?????????/ Always, there's only one truth!

From zbyszek at in.waw.pl  Fri Dec  3 19:53:42 2021
From: zbyszek at in.waw.pl (Zbigniew =?utf-8?Q?J=C4=99drzejewski-Szmek?=)
Date: Fri, 3 Dec 2021 19:53:42 +0000
Subject: [Rpm-ecosystem] why do elf dependency generators cover libraries in
 paths outside of the library load paths?
Message-ID: <20211203195342.GD1503@in.waw.pl>

We had an incident today [1] that opae-devel has auto-generated provides
like libcrypto.so.1.1()(64bit), generated for the bundled copy of openssl
(/usr/lib/python3.10/site-packages/pacsign/hsm_managers/openssl/library/libcrypto.so).
It was pulled into the buildroot instead of the expected openssl1.1 package.
Those deps are generated by /usr/lib/rpm/elfdeps, which is configured in
/usr/lib/rpm/fileattrs/elf.attr to act on anything that matches the
file magic of '^(setuid,? )?(setgid,? )?(sticky )?ELF (32|64)-bit.*$'.

My question: shouldn't we limit the elfdeps generator to files which
are in paths that can be loaded automatically by the linker? (This
could be implemented as e.g. the paths that are default like
/usr/lib64, /usr/local/lib64, ?, depending on the architecture, and if
the package installs anything in /etc/ld.so/, also the paths listed there.)

I always understood those Provides/Requires to be used for library
dependency resolution, and it doesn't seem to make sense to generate
them for plugins and other "private" objects outside of the linker
load paths.

I think it's much much more common to have .so libraries outside of
the linker paths for which we don't want the automatic provides
(python modules, java extensions, various loadable plugins), than to
have shared libraries in some custom directory. This should eliminate
most of the stupid issues where a "private" dependency leaks and
breaks other packages.

[1] bugzilla.redhat.com/2028852

Zbyszek

From ldv at altlinux.org  Fri Dec  3 20:51:26 2021
From: ldv at altlinux.org (Dmitry V. Levin)
Date: Fri, 3 Dec 2021 23:51:26 +0300
Subject: [Rpm-ecosystem] why do elf dependency generators cover
 libraries in paths outside of the library load paths?
In-Reply-To: <20211203195342.GD1503@in.waw.pl>
References: <20211203195342.GD1503@in.waw.pl>
Message-ID: <20211203205126.GA17492@altlinux.org>

On Fri, Dec 03, 2021 at 07:53:42PM +0000, Zbigniew J?drzejewski-Szmek wrote:
> We had an incident today [1] that opae-devel has auto-generated provides
> like libcrypto.so.1.1()(64bit), generated for the bundled copy of openssl
> (/usr/lib/python3.10/site-packages/pacsign/hsm_managers/openssl/library/libcrypto.so).
> It was pulled into the buildroot instead of the expected openssl1.1 package.
> Those deps are generated by /usr/lib/rpm/elfdeps, which is configured in
> /usr/lib/rpm/fileattrs/elf.attr to act on anything that matches the
> file magic of '^(setuid,? )?(setgid,? )?(sticky )?ELF (32|64)-bit.*$'.
> 
> My question: shouldn't we limit the elfdeps generator to files which
> are in paths that can be loaded automatically by the linker? (This
> could be implemented as e.g. the paths that are default like
> /usr/lib64, /usr/local/lib64, ?, depending on the architecture, and if
> the package installs anything in /etc/ld.so/, also the paths listed there.)

Back in 2006, I implemented the following semantics in ALT Sisyphus:
when Provides and Requires are generated for ELF shared libraries outside
of standard places searched by the dynamic linker, their directory prefix
is added, e.g.

$ rpmquery --provides -p firefox-94.0.2-alt1.x86_64.rpm |grep -F libmozsandbox.so
/usr/lib64/firefox/libmozsandbox.so()(64bit) = set:hd93tnnyHiEk678Zuue9vzWzvyhOXoj2

Hope this helps.


-- 
ldv

From ngompa13 at gmail.com  Wed Dec  8 15:04:19 2021
From: ngompa13 at gmail.com (Neal Gompa)
Date: Wed, 8 Dec 2021 10:04:19 -0500
Subject: [Rpm-ecosystem] [Rpm-maint] RFC: Relocate RPM and DNF databases
 to /usr
In-Reply-To: <3ffc1ffd-371c-347d-3c48-4eaed16a1f26@redhat.com>
References: <CAJCQCtQrKeZR6xM4bMwrM=sZhw+JZtcZtzd3VoLvEiM7fsc5xw@mail.gmail.com>
 <3ffc1ffd-371c-347d-3c48-4eaed16a1f26@redhat.com>
Message-ID: <CAEg-Je-_NMVbkmUAKtanzKmQmJCQ7UDM8h-SKBppu9cq1ScJOA@mail.gmail.com>

On Tue, Dec 7, 2021 at 9:05 AM Panu Matilainen <pmatilai at redhat.com> wrote:
>
> On 12/7/21 06:00, Chris Murphy wrote:
> > Hi RPM and DNF folks,
> >
> > I have a draft change proposal for review and comment, i.e. it's not yet
> > set to be published to Fedora devel at . It's a bit thin, but I expect to
> > fill in more detail following discussion in this thread.
> >
> > https://fedoraproject.org/wiki/Changes/RelocateRPMDNFToUsr
> > <https://fedoraproject.org/wiki/Changes/RelocateRPMDNFToUsr>
> >
> >
> > The prior discussions for RPM have happened here:
> > http://lists.rpm.org/pipermail/rpm-maint/2017-October/006681.html
> > <http://lists.rpm.org/pipermail/rpm-maint/2017-October/006681.html>
> > http://lists.rpm.org/pipermail/rpm-maint/2017-October/006723.html
> > <http://lists.rpm.org/pipermail/rpm-maint/2017-October/006723.html>
> >
> > Fedora 36 seems like a good time to do this. What do you think?
>
> rpm-maint is about upstream rpm changes, and for an upstream change, the
> earliest something this drastic could go in would be 4.18 next year,
> presumably aligning with Fedora 37.
>

The more appropriate list would have been rpm-ecosystem@, but many of
the same people are on this list anyway...

> > Is it a given that the relocation should (or must) happen for upgrades?
> > What concerns do you have about relocating both databases during
> > offline-upgrade and ensuring its crash safe? When should the relocation
> > happen; as first or last order of business, or other?
>
> It's not clear to me what exactly you're planning here. Are you talking
> about just following what openSUSE did or something more elaborate?
>
> Technically, pointing rpm to a different database is a matter of
> changing exactly one macro in the configuration. Upgrade business
> generally needs to be left to the distro as rpm will have no way of
> knowing when it's appropriate to migrate and when it's an old chroot
> you're only wanting to peek at. Querying those old chroots and other
> images is something people do quite a lot, and chasing the correct path
> without creating new ones on the way certainly requires more than just a
> macro change.

I think the idea is to pull off the same migration openSUSE did.


-- 
?????????/ Always, there's only one truth!

From jmracek at redhat.com  Thu Dec  9 10:00:50 2021
From: jmracek at redhat.com (Jaroslav Mracek)
Date: Thu, 9 Dec 2021 11:00:50 +0100
Subject: [Rpm-ecosystem] RFC: Relocate RPM and DNF databases to /usr
In-Reply-To: <CAJCQCtQrKeZR6xM4bMwrM=sZhw+JZtcZtzd3VoLvEiM7fsc5xw@mail.gmail.com>
References: <CAJCQCtQrKeZR6xM4bMwrM=sZhw+JZtcZtzd3VoLvEiM7fsc5xw@mail.gmail.com>
Message-ID: <CAG1svNgixpxvq9v5QwzUPOT6odkx5osx2ZqPV-ypqgpHvSqxhg@mail.gmail.com>

Hello Chris,

On Tue, Dec 7, 2021 at 5:01 AM Chris Murphy <lists at colorremedies.com> wrote:

> Hi RPM and DNF folks,
>
> I have a draft change proposal for review and comment, i.e. it's not yet
> set to be published to Fedora devel at . It's a bit thin, but I expect to
> fill in more detail following discussion in this thread.
>
> https://fedoraproject.org/wiki/Changes/RelocateRPMDNFToUsr
>

The change is not so simple. It is not only the movement of files from one
location to another one. We store more types of data in that location -
history database (sqlite), module failsafe data (yamls). In future we will
store system state data (toml). Data is not only modified after RPM
transactions but also by module and mark commands. What I want to say is
that the change will be painful but in the proposal there are limited
benefits.

There is also a question in which location DNF can move data. proposed
`/usr/lib/sysimage/dnf` is maybe not the best one.


>
>
>
> The prior discussions for RPM have happened here:
> http://lists.rpm.org/pipermail/rpm-maint/2017-October/006681.html
> http://lists.rpm.org/pipermail/rpm-maint/2017-October/006723.html
>
> Fedora 36 seems like a good time to do this. What do you think?
>

I don't think it is a good time to perform such a change from a DNF
perspective. We have a plan to introduce a major update to Fedora 38,
therefore it is a better time frame for such a change.


>
> Is it a given that the relocation should (or must) happen for upgrades?
> What concerns do you have about relocating both databases during
> offline-upgrade and ensuring its crash safe? When should the relocation
> happen; as first or last order of business, or other?
>
> --
> Chris Murphy
>

Jaroslav
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-ecosystem/attachments/20211209/1f0d4460/attachment.html>

From ngompa13 at gmail.com  Fri Dec 10 11:16:58 2021
From: ngompa13 at gmail.com (Neal Gompa)
Date: Fri, 10 Dec 2021 06:16:58 -0500
Subject: [Rpm-ecosystem] [Rpm-maint] RFC: Relocate RPM and DNF databases
 to /usr
In-Reply-To: <CAJCQCtTt_Sf+Hzu=U3gpX9ONum1ykSqbMSGET4SLH6wdx2YAcg@mail.gmail.com>
References: <CAJCQCtQrKeZR6xM4bMwrM=sZhw+JZtcZtzd3VoLvEiM7fsc5xw@mail.gmail.com>
 <CAG1svNgixpxvq9v5QwzUPOT6odkx5osx2ZqPV-ypqgpHvSqxhg@mail.gmail.com>
 <CAJCQCtTt_Sf+Hzu=U3gpX9ONum1ykSqbMSGET4SLH6wdx2YAcg@mail.gmail.com>
Message-ID: <CAEg-Je89dceE-rk6gOVjjqsHL+3rqRo2kPV5UmeMZspKYgn0-g@mail.gmail.com>

(Adding the correct Daniel Mach email address, he moved from Red Hat
to SUSE last month...)

On Thu, Dec 9, 2021 at 10:11 AM Chris Murphy <lists at colorremedies.com> wrote:
>
> On Thu, Dec 9, 2021 at 5:01 AM Jaroslav Mracek <jmracek at redhat.com> wrote:
> >
> > Hello Chris,
> >
> > On Tue, Dec 7, 2021 at 5:01 AM Chris Murphy <lists at colorremedies.com> wrote:
> >>
> >> Hi RPM and DNF folks,
> >>
> >> I have a draft change proposal for review and comment, i.e. it's not yet set to be published to Fedora devel at . It's a bit thin, but I expect to fill in more detail following discussion in this thread.
> >>
> >> https://fedoraproject.org/wiki/Changes/RelocateRPMDNFToUsr
> >
> >
> > The change is not so simple. It is not only the movement of files from one location to another one. We store more types of data in that location - history database (sqlite), module failsafe data (yamls). In future we will store system state data (toml). Data is not only modified after RPM transactions but also by module and mark commands. What I want to say is that the change will be painful but in the proposal there are limited benefits.
>
> I'm pretty sure I'm generally opposed to the idea of logs being rolled
> back (in a snapshot and rollback regime). Logs should always carry
> forward. Ideally, indicate relevant things like rollbacks in the log,
> because rolling back a log is a form of data loss. The history
> database sounds more like a log than not. So I'm getting squeamish
> about locating that somewhere else. Whereas system state information,
> if it's primarily describing /usr, sounds like it needs to get
> somewhere in /usr.
>

The history database is basically a transaction database like the
rpmdb is. It maps rpmdb transactions to dnf actions. So if you're
rolling back the rpm-managed content, it still makes sense to roll
back the history database, since that's the state of the system. It's
not terribly useful if the matching rpmdb transactions don't exist in
the rpmdb.

That said, the dnfdb is only *important* to move because it's required
for modularity stuff to work properly. Otherwise, it's not a huge deal
one way or another.

> Similar to openSUSE, design efforts around a default snapshot and
> rollback regime in Fedora are complicated when anything in /var
> depends on the state of /usr, and vice versa. As independent and
> interchangeable as they can be, I think the better.
>
> > There is also a question in which location DNF can move data. proposed `/usr/lib/sysimage/dnf` is maybe not the best one.
>
> What are some alternative suggestions?
>
>
> >> Fedora 36 seems like a good time to do this. What do you think?
> >
> >
> > I don't think it is a good time to perform such a change from a DNF perspective. We have a plan to introduce a major update to Fedora 38, therefore it is a better time frame for such a change.
>
> Is it better, worse, or indifferent if the RPM database location were
> changed in Fedora prior to any DNF change?
>

It won't matter. That's how it happened in openSUSE anyway. The rpmdb
path change happened several years earlier, and I changed the
dnfdb path in openSUSE at the top of the year as part of making the
DNF stack work properly on MicroOS.

https://code.opensuse.org/package/libdnf/c/37cdf99c506a7a2189ba26527d43665437c1db86

https://code.opensuse.org/package/dnf/c/24888ad21af0081e7432468d1aadfafd46e23526






--
?????????/ Always, there's only one truth!

From lhrazky at redhat.com  Fri Dec 10 12:39:34 2021
From: lhrazky at redhat.com (=?UTF-8?Q?Luk=C3=A1=C5=A1_Hr=C3=A1zk=C3=BD?=)
Date: Fri, 10 Dec 2021 13:39:34 +0100
Subject: [Rpm-ecosystem] [Rpm-maint] RFC: Relocate RPM and DNF databases
 to /usr
In-Reply-To: <CAEg-Je89dceE-rk6gOVjjqsHL+3rqRo2kPV5UmeMZspKYgn0-g@mail.gmail.com>
References: <CAJCQCtQrKeZR6xM4bMwrM=sZhw+JZtcZtzd3VoLvEiM7fsc5xw@mail.gmail.com>
 <CAG1svNgixpxvq9v5QwzUPOT6odkx5osx2ZqPV-ypqgpHvSqxhg@mail.gmail.com>
 <CAJCQCtTt_Sf+Hzu=U3gpX9ONum1ykSqbMSGET4SLH6wdx2YAcg@mail.gmail.com>
 <CAEg-Je89dceE-rk6gOVjjqsHL+3rqRo2kPV5UmeMZspKYgn0-g@mail.gmail.com>
Message-ID: <cf440a48b4cf0ab3337cbebf70df728a770c4755.camel@redhat.com>

On Fri, 2021-12-10 at 06:16 -0500, Neal Gompa wrote:
> (Adding the correct Daniel Mach email address, he moved from Red Hat
> to SUSE last month...)
> 
> On Thu, Dec 9, 2021 at 10:11 AM Chris Murphy <lists at colorremedies.com> wrote:
> > 
> > I'm pretty sure I'm generally opposed to the idea of logs being rolled
> > back (in a snapshot and rollback regime). Logs should always carry
> > forward. Ideally, indicate relevant things like rollbacks in the log,
> > because rolling back a log is a form of data loss. The history
> > database sounds more like a log than not. So I'm getting squeamish
> > about locating that somewhere else. Whereas system state information,
> > if it's primarily describing /usr, sounds like it needs to get
> > somewhere in /usr.
> > 
> 
> The history database is basically a transaction database like the
> rpmdb is. It maps rpmdb transactions to dnf actions.?

I'm not sure this is true at all. I haven't examined the rpmdb ever,
but AFAIK it contains the list of currently installed rpms (and their
data), but not the history as they came and went (i.e. a log).

OTOH dnf history database is exactly that. The current system state is
in dnf 4 also computed as the aggregation of the transactions in the
history database, which is IMO very wrong and we're fixing it in dnf 5.

> So if you're
> rolling back the rpm-managed content, it still makes sense to roll
> back the history database, since that's the state of the system. It's
> not terribly useful if the matching rpmdb transactions don't exist in
> the rpmdb.

Conceptually I agree with Chris on this: We shouldn't roll back the log
of transactions if we'd be rolling back the system itself. That way you
in effect erase that the system was running in a different state for an
amount of time, imagine an auditing situation.

There are also issues with sqlite creating some lock files even if just
reading, which wouldn't be possible on a RO FS (IIRC how it was
explained to me), so there are other reasons why the history db will
likely not move to /usr.

> That said, the dnfdb is only *important* to move because it's required
> for modularity stuff to work properly. Otherwise, it's not a huge deal
> one way or another.

Please don't introduce dnfdb as a term, AFAIK it doesn't exist :P

If there's anything in history db that is required for modularity to be
functional on a system, it should be moved to the dnf system state (in
dnf 5), history db should just be a log and nothing else (at most we
could use it to reconstruct the system state if it gets damaged while
the history db remains intact).

Cheers,
Lukas


From lists at colorremedies.com  Fri Dec 10 18:53:06 2021
From: lists at colorremedies.com (Chris Murphy)
Date: Fri, 10 Dec 2021 13:53:06 -0500
Subject: [Rpm-ecosystem] [Rpm-maint] RFC: Relocate RPM and DNF databases
 to /usr
In-Reply-To: <cf440a48b4cf0ab3337cbebf70df728a770c4755.camel@redhat.com>
References: <CAJCQCtQrKeZR6xM4bMwrM=sZhw+JZtcZtzd3VoLvEiM7fsc5xw@mail.gmail.com>
 <CAG1svNgixpxvq9v5QwzUPOT6odkx5osx2ZqPV-ypqgpHvSqxhg@mail.gmail.com>
 <CAJCQCtTt_Sf+Hzu=U3gpX9ONum1ykSqbMSGET4SLH6wdx2YAcg@mail.gmail.com>
 <CAEg-Je89dceE-rk6gOVjjqsHL+3rqRo2kPV5UmeMZspKYgn0-g@mail.gmail.com>
 <cf440a48b4cf0ab3337cbebf70df728a770c4755.camel@redhat.com>
Message-ID: <CAJCQCtRBGaZKpYQULnyLR+3hqfzjWW8Vt2fbenaWN7opYqBE_w@mail.gmail.com>

{
Apologies for not sending to rpm-ecosystem@ first off [1], then b.
since I wasn't subscribed to rpm-ecosystem@ my reply [2] was dropped,
messing up the threading.
[1] http://lists.rpm.org/pipermail/rpm-maint/2021-December/018662.html
[2] http://lists.rpm.org/pipermail/rpm-maint/2021-December/018687.html
}

On Fri, Dec 10, 2021 at 7:39 AM Luk?? Hr?zk? <lhrazky at redhat.com> wrote:
>
> On Fri, 2021-12-10 at 06:16 -0500, Neal Gompa wrote:
> > (Adding the correct Daniel Mach email address, he moved from Red Hat
> > to SUSE last month...)
> >
> > On Thu, Dec 9, 2021 at 10:11 AM Chris Murphy <lists at colorremedies.com> wrote:
> > >
> > > I'm pretty sure I'm generally opposed to the idea of logs being rolled
> > > back (in a snapshot and rollback regime). Logs should always carry
> > > forward. Ideally, indicate relevant things like rollbacks in the log,
> > > because rolling back a log is a form of data loss. The history
> > > database sounds more like a log than not. So I'm getting squeamish
> > > about locating that somewhere else. Whereas system state information,
> > > if it's primarily describing /usr, sounds like it needs to get
> > > somewhere in /usr.
> > >
> >
> > The history database is basically a transaction database like the
> > rpmdb is. It maps rpmdb transactions to dnf actions.
>
> I'm not sure this is true at all. I haven't examined the rpmdb ever,
> but AFAIK it contains the list of currently installed rpms (and their
> data), but not the history as they came and went (i.e. a log).
>
> OTOH dnf history database is exactly that. The current system state is
> in dnf 4 also computed as the aggregation of the transactions in the
> history database, which is IMO very wrong and we're fixing it in dnf 5.

What's the timeframe for dnf 5 as it relates to the Fedora release cycle?

>
> > So if you're
> > rolling back the rpm-managed content, it still makes sense to roll
> > back the history database, since that's the state of the system. It's
> > not terribly useful if the matching rpmdb transactions don't exist in
> > the rpmdb.
>
> Conceptually I agree with Chris on this: We shouldn't roll back the log
> of transactions if we'd be rolling back the system itself. That way you
> in effect erase that the system was running in a different state for an
> amount of time, imagine an auditing situation.

Yeah, the auditing case is important to consider. The FHS can be
aggravating in the context of snapshot and rollback regimes, in
particular deciding whether a /usr /var and /etc are tied to each
other for all time or if they can be mix and match. And that brings up
how to name the snapshots (I've varied between simple version control
by tacking on a .1 .2 .3 counter; to using ISO 8601 datetime stamps)
and whether and how to do system assembly at startup [3].

[3] need for a discoverable subvolumes specification (thread crosses two months)
https://lists.freedesktop.org/archives/systemd-devel/2021-November/047059.html
https://lists.freedesktop.org/archives/systemd-devel/2021-December/047176.html

For my non-emphemeral systems:

* /usr /var /etc are directories contained in btrfs subvolume
"root-x86-64:fedora.35"
* read-only snapshots have an ISO 8601 datetime format tacked onto the end

* /var/log is a directory contained in subvolume "varlog-x86-64:fedora.35"
* /var/lib/libvirt/images is a directory contained in subvolume
"varlibvirtimages-x86-64:fedora.35"
* no snapshots are ever made of these; by virtue of themselves being
subvolumes, any snapshot of "root-x86-64:fedora.35" doesn't contain
/var/log or /var/lib/libvirt/images so just like /home, they only ever
carry forward in time.

Therefore in my case, snapshot and rollback doesn't affect any logs,
including the systemd journal. They only ever carry forward in time.
Same for VM images and for ~/ since that lives in /home and is a
separate subvolume too by default in Fedora. But both RPM database and
DNF history do get rolled back in this case. Which works out OK
because usr/ var/ etc/ are all in one root. A rollback means DNF
history still accurately describes that root's history and state.

As soon as there's mix and match any of usr/ var/ and etc/ it gets trickier.

> There are also issues with sqlite creating some lock files even if just
> reading, which wouldn't be possible on a RO FS (IIRC how it was
> explained to me), so there are other reasons why the history db will
> likely not move to /usr.

Detect it and use overlayfs on a volatile /run directory for this use
case? I'm not sure the use case really calls for a persistent file
that survives a crash for reading read-only files?

> If there's anything in history db that is required for modularity to be
> functional on a system, it should be moved to the dnf system state (in
> dnf 5), history db should just be a log and nothing else (at most we
> could use it to reconstruct the system state if it gets damaged while
> the history db remains intact).


I wonder if the dnf history ought to go in /var/log and be exempt like
the systemd journal? Or maybe for auditing purposes it should write to
both its own history file as well as into the systemd journal?


--
Chris Murphy

From lhrazky at redhat.com  Mon Dec 13 15:07:32 2021
From: lhrazky at redhat.com (=?UTF-8?Q?Luk=C3=A1=C5=A1_Hr=C3=A1zk=C3=BD?=)
Date: Mon, 13 Dec 2021 16:07:32 +0100
Subject: [Rpm-ecosystem] [Rpm-maint] RFC: Relocate RPM and DNF databases
 to /usr
In-Reply-To: <40332836-968f-2945-0347-94c26f1d65b8@suse.com>
References: <CAJCQCtQrKeZR6xM4bMwrM=sZhw+JZtcZtzd3VoLvEiM7fsc5xw@mail.gmail.com>
 <CAG1svNgixpxvq9v5QwzUPOT6odkx5osx2ZqPV-ypqgpHvSqxhg@mail.gmail.com>
 <CAJCQCtTt_Sf+Hzu=U3gpX9ONum1ykSqbMSGET4SLH6wdx2YAcg@mail.gmail.com>
 <CAEg-Je89dceE-rk6gOVjjqsHL+3rqRo2kPV5UmeMZspKYgn0-g@mail.gmail.com>
 <cf440a48b4cf0ab3337cbebf70df728a770c4755.camel@redhat.com>
 <40332836-968f-2945-0347-94c26f1d65b8@suse.com>
Message-ID: <813f0139339ce954e387e65fe8fd8d88dc7bae96.camel@redhat.com>

On Fri, 2021-12-10 at 17:08 +0100, Daniel Mach wrote:
> On 10. 12. 21 13:39, Luk?? Hr?zk? wrote:
> > On Fri, 2021-12-10 at 06:16 -0500, Neal Gompa wrote:
> > > (Adding the correct Daniel Mach email address, he moved from Red Hat
> > > to SUSE last month...)
> > > 
> > > On Thu, Dec 9, 2021 at 10:11 AM Chris Murphy <lists at colorremedies.com> wrote:
> > > > I'm pretty sure I'm generally opposed to the idea of logs being rolled
> > > > back (in a snapshot and rollback regime). Logs should always carry
> > > > forward. Ideally, indicate relevant things like rollbacks in the log,
> > > > because rolling back a log is a form of data loss. The history
> > > > database sounds more like a log than not. So I'm getting squeamish
> > > > about locating that somewhere else. Whereas system state information,
> > > > if it's primarily describing /usr, sounds like it needs to get
> > > > somewhere in /usr.
> > > > 
> > > The history database is basically a transaction database like the
> > > rpmdb is. It maps rpmdb transactions to dnf actions.
> > I'm not sure this is true at all. I haven't examined the rpmdb ever,
> > but AFAIK it contains the list of currently installed rpms (and their
> > data), but not the history as they came and went (i.e. a log).
> > 
> > OTOH dnf history database is exactly that. The current system state is
> > in dnf 4 also computed as the aggregation of the transactions in the
> > history database, which is IMO very wrong and we're fixing it in dnf 5.
> > 
> > > So if you're
> > > rolling back the rpm-managed content, it still makes sense to roll
> > > back the history database, since that's the state of the system. It's
> > > not terribly useful if the matching rpmdb transactions don't exist in
> > > the rpmdb.
> > Conceptually I agree with Chris on this: We shouldn't roll back the log
> > of transactions if we'd be rolling back the system itself. That way you
> > in effect erase that the system was running in a different state for an
> > amount of time, imagine an auditing situation.
> 
> As a user, I wouldn't expect history db to contain transactions that are 
> not relevant to my system.
> If I do filesystem rollback, I'd probably want to rollback even the 
> history db.
> Also, if we don't rollback history db too, it's going to break `dnf 
> history rollback` functionality.
> 
> I understand your point about auditing, but does DNF have to handle 
> everything?
> There should be better options of tracking filesystem rollbacks than 
> DNF's history database.
> 

Maybe, but the history DB still contains a log of events as they
happened over time, I don't think that belongs to /usr.

> > There are also issues with sqlite creating some lock files even if just
> > reading, which wouldn't be possible on a RO FS (IIRC how it was
> > explained to me), so there are other reasons why the history db will
> > likely not move to /usr.
> If it's the same location where rpmdb is supposed to live, it's probably ok.
> AFAIK its rw when you change the image and ro when you use it.
> > 
> > > That said, the dnfdb is only *important* to move because it's required
> > > for modularity stuff to work properly. Otherwise, it's not a huge deal
> > > one way or another.
> > Please don't introduce dnfdb as a term, AFAIK it doesn't exist :P
> > 
> > If there's anything in history db that is required for modularity to be
> > functional on a system, it should be moved to the dnf system state (in
> > dnf 5), history db should just be a log and nothing else (at most we
> > could use it to reconstruct the system state if it gets damaged while
> > the history db remains intact).
> It's mainly comps that lives nowhere else than in history db - and this 
> must be fixed by introducing "@System" (== installed) data for comps.
> Modularity mainly relies on data in /etc, but it is similar problem to 
> comps above.
> 

Even more importantly, history DB now contains the list of
userinstalled packages (which also lives nowhere else).


From lhrazky at redhat.com  Mon Dec 13 15:08:52 2021
From: lhrazky at redhat.com (=?UTF-8?Q?Luk=C3=A1=C5=A1_Hr=C3=A1zk=C3=BD?=)
Date: Mon, 13 Dec 2021 16:08:52 +0100
Subject: [Rpm-ecosystem] [Rpm-maint] RFC: Relocate RPM and DNF databases
 to /usr
In-Reply-To: <CAJCQCtRBGaZKpYQULnyLR+3hqfzjWW8Vt2fbenaWN7opYqBE_w@mail.gmail.com>
References: <CAJCQCtQrKeZR6xM4bMwrM=sZhw+JZtcZtzd3VoLvEiM7fsc5xw@mail.gmail.com>
 <CAG1svNgixpxvq9v5QwzUPOT6odkx5osx2ZqPV-ypqgpHvSqxhg@mail.gmail.com>
 <CAJCQCtTt_Sf+Hzu=U3gpX9ONum1ykSqbMSGET4SLH6wdx2YAcg@mail.gmail.com>
 <CAEg-Je89dceE-rk6gOVjjqsHL+3rqRo2kPV5UmeMZspKYgn0-g@mail.gmail.com>
 <cf440a48b4cf0ab3337cbebf70df728a770c4755.camel@redhat.com>
 <CAJCQCtRBGaZKpYQULnyLR+3hqfzjWW8Vt2fbenaWN7opYqBE_w@mail.gmail.com>
Message-ID: <df9b00b7f8784017daf79284c6c6e1cd4b4bbdfc.camel@redhat.com>

On Fri, 2021-12-10 at 13:53 -0500, Chris Murphy wrote:
> {
> Apologies for not sending to rpm-ecosystem@ first off [1], then b.
> since I wasn't subscribed to rpm-ecosystem@ my reply [2] was dropped,
> messing up the threading.
> [1] http://lists.rpm.org/pipermail/rpm-maint/2021-December/018662.html
> [2] http://lists.rpm.org/pipermail/rpm-maint/2021-December/018687.html
> }
> 
> On Fri, Dec 10, 2021 at 7:39 AM Luk?? Hr?zk? <lhrazky at redhat.com> wrote:
> > 
> > On Fri, 2021-12-10 at 06:16 -0500, Neal Gompa wrote:
> > > (Adding the correct Daniel Mach email address, he moved from Red Hat
> > > to SUSE last month...)
> > > 
> > > On Thu, Dec 9, 2021 at 10:11 AM Chris Murphy <lists at colorremedies.com> wrote:
> > > > 
> > > > I'm pretty sure I'm generally opposed to the idea of logs being rolled
> > > > back (in a snapshot and rollback regime). Logs should always carry
> > > > forward. Ideally, indicate relevant things like rollbacks in the log,
> > > > because rolling back a log is a form of data loss. The history
> > > > database sounds more like a log than not. So I'm getting squeamish
> > > > about locating that somewhere else. Whereas system state information,
> > > > if it's primarily describing /usr, sounds like it needs to get
> > > > somewhere in /usr.
> > > > 
> > > 
> > > The history database is basically a transaction database like the
> > > rpmdb is. It maps rpmdb transactions to dnf actions.
> > 
> > I'm not sure this is true at all. I haven't examined the rpmdb ever,
> > but AFAIK it contains the list of currently installed rpms (and their
> > data), but not the history as they came and went (i.e. a log).
> > 
> > OTOH dnf history database is exactly that. The current system state is
> > in dnf 4 also computed as the aggregation of the transactions in the
> > history database, which is IMO very wrong and we're fixing it in dnf 5.
> 
> What's the timeframe for dnf 5 as it relates to the Fedora release cycle?
> 

The aim is to release dnf 5 in Fedora 38. Long before that we should
have a sort-of tech preview (as soon as it's somewhat consistently
working) and transition it into alpha/beta releases for testing, we'll
still be figuring out how to do that exactly.

> > > So if you're
> > > rolling back the rpm-managed content, it still makes sense to roll
> > > back the history database, since that's the state of the system. It's
> > > not terribly useful if the matching rpmdb transactions don't exist in
> > > the rpmdb.
> > 
> > Conceptually I agree with Chris on this: We shouldn't roll back the log
> > of transactions if we'd be rolling back the system itself. That way you
> > in effect erase that the system was running in a different state for an
> > amount of time, imagine an auditing situation.
> 
> Yeah, the auditing case is important to consider. The FHS can be
> aggravating in the context of snapshot and rollback regimes, in
> particular deciding whether a /usr /var and /etc are tied to each
> other for all time or if they can be mix and match. And that brings up
> how to name the snapshots (I've varied between simple version control
> by tacking on a .1 .2 .3 counter; to using ISO 8601 datetime stamps)
> and whether and how to do system assembly at startup [3].
> 
> [3] need for a discoverable subvolumes specification (thread crosses two months)
> https://lists.freedesktop.org/archives/systemd-devel/2021-November/047059.html
> https://lists.freedesktop.org/archives/systemd-devel/2021-December/047176.html
> 
> For my non-emphemeral systems:
> 
> * /usr /var /etc are directories contained in btrfs subvolume
> "root-x86-64:fedora.35"
> * read-only snapshots have an ISO 8601 datetime format tacked onto the end
> 
> * /var/log is a directory contained in subvolume "varlog-x86-64:fedora.35"
> * /var/lib/libvirt/images is a directory contained in subvolume
> "varlibvirtimages-x86-64:fedora.35"
> * no snapshots are ever made of these; by virtue of themselves being
> subvolumes, any snapshot of "root-x86-64:fedora.35" doesn't contain
> /var/log or /var/lib/libvirt/images so just like /home, they only ever
> carry forward in time.
> 
> Therefore in my case, snapshot and rollback doesn't affect any logs,
> including the systemd journal. They only ever carry forward in time.
> Same for VM images and for ~/ since that lives in /home and is a
> separate subvolume too by default in Fedora. But both RPM database and
> DNF history do get rolled back in this case. Which works out OK
> because usr/ var/ etc/ are all in one root. A rollback means DNF
> history still accurately describes that root's history and state.
> 
> As soon as there's mix and match any of usr/ var/ and etc/ it gets trickier.

So, is this basically the summary of your motivation for this change?
That rollbacks of your /usr is always in sync with the dnf-stored
system state?

FWIW we could do with a practical evaluation of impact and issues this
is causing now, are we talking desktops/servers/containers, etc.?

So far this looks like it can wait for dnf 5.

> > There are also issues with sqlite creating some lock files even if just
> > reading, which wouldn't be possible on a RO FS (IIRC how it was
> > explained to me), so there are other reasons why the history db will
> > likely not move to /usr.
> 
> Detect it and use overlayfs on a volatile /run directory for this use
> case? I'm not sure the use case really calls for a persistent file
> that survives a crash for reading read-only files?

AFAICT it doesn't require a persistent file. But if you're suggesting
for dnf itself to set up that overlayfs, I may be misjudging, but it
seems way out of bounds of what dnf should be doing.

But the situation may be solvable in other ways, e.g. storing those
files in a writable temporary location. I haven't investigated.

Tbh. given the ugliness and complexity added by history DB and how it
stores the system state (you seem to agree the transaction log
shouldn't be on /usr, but those two are stored together now) I doubt
we'll resolve this before dnf 5, unless there's a contribution which
neatly ties the loose ends (again, dnf 4 is ugly in a lot of ways...)

> > If there's anything in history db that is required for modularity to be
> > functional on a system, it should be moved to the dnf system state (in
> > dnf 5), history db should just be a log and nothing else (at most we
> > could use it to reconstruct the system state if it gets damaged while
> > the history db remains intact).
> 
> 
> I wonder if the dnf history ought to go in /var/log and be exempt like
> the systemd journal? Or maybe for auditing purposes it should write to
> both its own history file as well as into the systemd journal?

I guess for auditing you could do with a simple text log of the
transactions. The history DB supports querying and also undo/redo, so
it's a more sophisticated solution. There have been requests for that
simple log (in addition to the history DB) exactly because of
simplicity. But I don't think we'd want to store history DB in
/var/log.

/var/lib still seems like the arguably best place for it to me.

Cheers,
Lukas


From lists at colorremedies.com  Mon Dec 13 18:02:02 2021
From: lists at colorremedies.com (Chris Murphy)
Date: Mon, 13 Dec 2021 13:02:02 -0500
Subject: [Rpm-ecosystem] [Rpm-maint] RFC: Relocate RPM and DNF databases
 to /usr
In-Reply-To: <813f0139339ce954e387e65fe8fd8d88dc7bae96.camel@redhat.com>
References: <CAJCQCtQrKeZR6xM4bMwrM=sZhw+JZtcZtzd3VoLvEiM7fsc5xw@mail.gmail.com>
 <CAG1svNgixpxvq9v5QwzUPOT6odkx5osx2ZqPV-ypqgpHvSqxhg@mail.gmail.com>
 <CAJCQCtTt_Sf+Hzu=U3gpX9ONum1ykSqbMSGET4SLH6wdx2YAcg@mail.gmail.com>
 <CAEg-Je89dceE-rk6gOVjjqsHL+3rqRo2kPV5UmeMZspKYgn0-g@mail.gmail.com>
 <cf440a48b4cf0ab3337cbebf70df728a770c4755.camel@redhat.com>
 <40332836-968f-2945-0347-94c26f1d65b8@suse.com>
 <813f0139339ce954e387e65fe8fd8d88dc7bae96.camel@redhat.com>
Message-ID: <CAJCQCtTWjW3JPCHwcSu7s3md4ouA4ziwPtPkRshZ2gAnPRBUzQ@mail.gmail.com>

On Mon, Dec 13, 2021 at 10:07 AM Luk?? Hr?zk? <lhrazky at redhat.com> wrote:
>
> On Fri, 2021-12-10 at 17:08 +0100, Daniel Mach wrote:

> > I understand your point about auditing, but does DNF have to handle
> > everything?
> > There should be better options of tracking filesystem rollbacks than
> > DNF's history database.
> >
>
> Maybe, but the history DB still contains a log of events as they
> happened over time, I don't think that belongs to /usr.

How about:

For read-write /usr store any database describing /usr state in
/usr/lib/sysimage
For read-only /usr store any database describing /usr state in
/var/lib/dnf with a /usr/lib/sysimage symlink pointing to it
/var is always read-write so any database describing /var state goes
in /var/lib/dnf

This suggests that anything that can describe state, should have
separate databases for /usr and /var. I don't know to what degree dnf
touches various top level FHS directories: /var /usr /etc /home and so
on. But I wonder if the history databases should separately track the
things being touched?



-- 
Chris Murphy

From lists at colorremedies.com  Mon Dec 13 18:48:16 2021
From: lists at colorremedies.com (Chris Murphy)
Date: Mon, 13 Dec 2021 13:48:16 -0500
Subject: [Rpm-ecosystem] [Rpm-maint] RFC: Relocate RPM and DNF databases
 to /usr
In-Reply-To: <df9b00b7f8784017daf79284c6c6e1cd4b4bbdfc.camel@redhat.com>
References: <CAJCQCtQrKeZR6xM4bMwrM=sZhw+JZtcZtzd3VoLvEiM7fsc5xw@mail.gmail.com>
 <CAG1svNgixpxvq9v5QwzUPOT6odkx5osx2ZqPV-ypqgpHvSqxhg@mail.gmail.com>
 <CAJCQCtTt_Sf+Hzu=U3gpX9ONum1ykSqbMSGET4SLH6wdx2YAcg@mail.gmail.com>
 <CAEg-Je89dceE-rk6gOVjjqsHL+3rqRo2kPV5UmeMZspKYgn0-g@mail.gmail.com>
 <cf440a48b4cf0ab3337cbebf70df728a770c4755.camel@redhat.com>
 <CAJCQCtRBGaZKpYQULnyLR+3hqfzjWW8Vt2fbenaWN7opYqBE_w@mail.gmail.com>
 <df9b00b7f8784017daf79284c6c6e1cd4b4bbdfc.camel@redhat.com>
Message-ID: <CAJCQCtRbDdEfcbPN8bohTY9wQeRESU_7Ke4u64MvGpshyFSBaw@mail.gmail.com>

On Mon, Dec 13, 2021 at 10:09 AM Luk?? Hr?zk? <lhrazky at redhat.com> wrote:
>
> On Fri, 2021-12-10 at 13:53 -0500, Chris Murphy wrote:

> > For my non-emphemeral systems:
> >
> > * /usr /var /etc are directories contained in btrfs subvolume
> > "root-x86-64:fedora.35"
> > * read-only snapshots have an ISO 8601 datetime format tacked onto the end
> >
> > * /var/log is a directory contained in subvolume "varlog-x86-64:fedora.35"
> > * /var/lib/libvirt/images is a directory contained in subvolume
> > "varlibvirtimages-x86-64:fedora.35"
> > * no snapshots are ever made of these; by virtue of themselves being
> > subvolumes, any snapshot of "root-x86-64:fedora.35" doesn't contain
> > /var/log or /var/lib/libvirt/images so just like /home, they only ever
> > carry forward in time.
> >
> > Therefore in my case, snapshot and rollback doesn't affect any logs,
> > including the systemd journal. They only ever carry forward in time.
> > Same for VM images and for ~/ since that lives in /home and is a
> > separate subvolume too by default in Fedora. But both RPM database and
> > DNF history do get rolled back in this case. Which works out OK
> > because usr/ var/ etc/ are all in one root. A rollback means DNF
> > history still accurately describes that root's history and state.
> >
> > As soon as there's mix and match any of usr/ var/ and etc/ it gets trickier.
>
> So, is this basically the summary of your motivation for this change?
> That rollbacks of your /usr is always in sync with the dnf-stored
> system state?

Tentative answer is yes. But does dnf-stored system state mean /usr
state or /var state or both? And is anything else included?


> FWIW we could do with a practical evaluation of impact and issues this
> is causing now, are we talking desktops/servers/containers, etc.?

Desktops, servers, virtual machines. My thought about containers is
that they are self-contained, i.e. /usr and /var are paired together
for the life of a container, and there isn't a roll for mixing and
matching /usr and /var for a given container. There are technologies
that can make this trivially possible so will it happen? *shrug* no
idea. But right now if you had to do a rollback, I'd expect you start
a new container predicated on a previous state of a container image,
i.e. manage container versioning+snapshot+rollback within the
container realm, not with the tools inside of it. The idea of using
snapper to maintain many container variants inside a container just
seems a bit mind boggling to me but I guess it could happen.



> > > There are also issues with sqlite creating some lock files even if just
> > > reading, which wouldn't be possible on a RO FS (IIRC how it was
> > > explained to me), so there are other reasons why the history db will
> > > likely not move to /usr.
> >
> > Detect it and use overlayfs on a volatile /run directory for this use
> > case? I'm not sure the use case really calls for a persistent file
> > that survives a crash for reading read-only files?
>
> AFAICT it doesn't require a persistent file. But if you're suggesting
> for dnf itself to set up that overlayfs, I may be misjudging, but it
> seems way out of bounds of what dnf should be doing.

Neither sqlite nor dnf must have this ability, I'm suggesting they
could do it. As in, it's not improper. If dnf must create lock files
in order to read files on a read-only system, then the choice is (I'm
guessing) to either fail or to setup an overlay or even use /tmp in
order to not fail. And i'm not suggesting which choice is right or
wrong, just that no matter what there's some consequence.

Ideally, I'd expect a system should anticipate the read-only /usr
requirements, and that its initramfs would have the ability to detect
read-only /usr and setup a volatile overlay on /run using overlayfs,
similar to a LiveOS boot. In such a case, it's transparent to
software. It'll look like a read-write system. It's just that any
changes will be lost at reboot because all the changes are stored on a
volatile storage. And the UI is either "user expressly chose a rescue
boot which implies this kind of volatile environment" or "the
environment notifies the user that the environment is on volatile
storage".


> But the situation may be solvable in other ways, e.g. storing those
> files in a writable temporary location. I haven't investigated.

Sure.

> Tbh. given the ugliness and complexity added by history DB and how it
> stores the system state (you seem to agree the transaction log
> shouldn't be on /usr, but those two are stored together now) I doubt
> we'll resolve this before dnf 5, unless there's a contribution which
> neatly ties the loose ends (again, dnf 4 is ugly in a lot of ways...)

I'm definitely reluctant to consider conflating logs and state in the
same file. Those seem like really different things. A log can't
reliably infer state by replaying the log unless that log contains all
things that can affect state, including events that dnf doesn't
control. That's a tall order.

If dnf can affect /home then maybe it calls for separate ~/ state
tracking because users can do rollbacks of individual user homes. The
ordinary case of rollback is really just restoring a file from a
previous state. The extraordinary case is restoring a user's home from
backup. We only explore the various technologies for achieving this,
in order to deconflict. Not because any one method should be promoted.
It doesn't matter if a user's home is restored by rsync, or by a btrfs
send/receive of a snapshot. Either way the whole user home has in
effect been rolled back to the state it was in when last backedup (and
is now restored). So you probably don't want to have a database for
/home but rather for each user's /home.



>
> > > If there's anything in history db that is required for modularity to be
> > > functional on a system, it should be moved to the dnf system state (in
> > > dnf 5), history db should just be a log and nothing else (at most we
> > > could use it to reconstruct the system state if it gets damaged while
> > > the history db remains intact).
> >
> >
> > I wonder if the dnf history ought to go in /var/log and be exempt like
> > the systemd journal? Or maybe for auditing purposes it should write to
> > both its own history file as well as into the systemd journal?
>
> I guess for auditing you could do with a simple text log of the
> transactions. The history DB supports querying and also undo/redo, so
> it's a more sophisticated solution. There have been requests for that
> simple log (in addition to the history DB) exactly because of
> simplicity. But I don't think we'd want to store history DB in
> /var/log.
>
> /var/lib still seems like the arguably best place for it to me.

Well... the difficulty is if /var is rolled back but /usr isn't or
vice versa. The log in /var/lib will somehow be wrong no matter what
in such a case.

Maybe worth exploring the question as true or false: dnf doesn't
support mix and match /usr /var states, those two directories are
assumed to be paired together for life

If it's false or you want it to be false, then what needs to be
changed so dnf can independently track state changes to them?


-- 
Chris Murphy

From walters at verbum.org  Tue Dec 14 20:59:47 2021
From: walters at verbum.org (Colin Walters)
Date: Tue, 14 Dec 2021 15:59:47 -0500
Subject: [Rpm-ecosystem] RFC: Relocate RPM and DNF databases to /usr
In-Reply-To: <CAJCQCtTt_Sf+Hzu=U3gpX9ONum1ykSqbMSGET4SLH6wdx2YAcg@mail.gmail.com>
References: <CAJCQCtQrKeZR6xM4bMwrM=sZhw+JZtcZtzd3VoLvEiM7fsc5xw@mail.gmail.com>
 <CAG1svNgixpxvq9v5QwzUPOT6odkx5osx2ZqPV-ypqgpHvSqxhg@mail.gmail.com>
 <CAJCQCtTt_Sf+Hzu=U3gpX9ONum1ykSqbMSGET4SLH6wdx2YAcg@mail.gmail.com>
Message-ID: <acd820fd-6b48-4da8-a95c-eefe782fbe25@www.fastmail.com>



On Thu, Dec 9, 2021, at 10:11 AM, Chris Murphy wrote:

>> The change is not so simple. It is not only the movement of files from one location to another one. We store more types of data in that location - history database (sqlite), module failsafe data (yamls). In future we will store system state data (toml). Data is not only modified after RPM transactions but also by module and mark commands. What I want to say is that the change will be painful but in the proposal there are limited benefits.

When the rpmdb was bdb and not extensible, I understand the idea of dnf having its own separate database.  But I don't understand why there are two separate sqlite databases now.

Anyways, a lot going on here and rather than point by point I'll say basically:

It'd be great from the rpm-ostree PoV to have a shared consistent place for the rpmdb.  Last time this came up I think Panu really wanted to get the sqlite change out first, which - fair.  But now that's done, so are there any other blockers?

We could try simply not changing existing systems in-place at first, but just do it for new installs, add the backcompat symlink, ensure the stack looks in both places (preferring new); that's actually mostly done AFAIK.

Today rpm-ostree has its own state management that doesn't use the libdnf history stuff.  Longer term it would be good to have a unified vision there - most of this is touched on in https://github.com/coreos/rpm-ostree/issues/2326

But I think I'm arguing to decouple the rpmdb move from the dnf move.

From pmatilai at redhat.com  Wed Dec 15 09:09:14 2021
From: pmatilai at redhat.com (Panu Matilainen)
Date: Wed, 15 Dec 2021 11:09:14 +0200
Subject: [Rpm-ecosystem] RFC: Relocate RPM and DNF databases to /usr
In-Reply-To: <acd820fd-6b48-4da8-a95c-eefe782fbe25@www.fastmail.com>
References: <CAJCQCtQrKeZR6xM4bMwrM=sZhw+JZtcZtzd3VoLvEiM7fsc5xw@mail.gmail.com>
 <CAG1svNgixpxvq9v5QwzUPOT6odkx5osx2ZqPV-ypqgpHvSqxhg@mail.gmail.com>
 <CAJCQCtTt_Sf+Hzu=U3gpX9ONum1ykSqbMSGET4SLH6wdx2YAcg@mail.gmail.com>
 <acd820fd-6b48-4da8-a95c-eefe782fbe25@www.fastmail.com>
Message-ID: <5c963491-947a-536c-ef8a-3aad62dc497e@redhat.com>

On 12/14/21 22:59, Colin Walters wrote:
> 
> 
> On Thu, Dec 9, 2021, at 10:11 AM, Chris Murphy wrote:
> 
>>> The change is not so simple. It is not only the movement of files from one location to another one. We store more types of data in that location - history database (sqlite), module failsafe data (yamls). In future we will store system state data (toml). Data is not only modified after RPM transactions but also by module and mark commands. What I want to say is that the change will be painful but in the proposal there are limited benefits.
> 
> When the rpmdb was bdb and not extensible, I understand the idea of dnf having its own separate database.  But I don't understand why there are two separate sqlite databases now.

The rpmdb is not hard-wired to sqlite. Also, whatever the format used 
it's strictly private to rpm except what's exposed through librpm APIs. 
So it's certainly NOT extensible in the sense that anybody wanting to 
put something package related there is free to do so.

> 
> Anyways, a lot going on here and rather than point by point I'll say basically:
> 
> It'd be great from the rpm-ostree PoV to have a shared consistent place for the rpmdb.  Last time this came up I think Panu really wanted to get the sqlite change out first, which - fair.  But now that's done, so are there any other blockers?

Just the pain and misery of dealing with a fundamental change that has 
zero benefit to rpm itself. It'll be a long, long, long time before 
/var/lib/rpm is phased out of existence for good, and in the meanwhile 
us rpm f get to answer all the questions and complaints about it. I'm 
not looking forward to that.

	- Panu -

> 
> We could try simply not changing existing systems in-place at first, but just do it for new installs, add the backcompat symlink, ensure the stack looks in both places (preferring new); that's actually mostly done AFAIK.
> 
> Today rpm-ostree has its own state management that doesn't use the libdnf history stuff.  Longer term it would be good to have a unified vision there - most of this is touched on in https://github.com/coreos/rpm-ostree/issues/2326
> 
> But I think I'm arguing to decouple the rpmdb move from the dnf move.
> 


From lists at colorremedies.com  Wed Dec 15 21:08:59 2021
From: lists at colorremedies.com (Chris Murphy)
Date: Wed, 15 Dec 2021 16:08:59 -0500
Subject: [Rpm-ecosystem] RFC: Relocate RPM and DNF databases to /usr
In-Reply-To: <5c963491-947a-536c-ef8a-3aad62dc497e@redhat.com>
References: <CAJCQCtQrKeZR6xM4bMwrM=sZhw+JZtcZtzd3VoLvEiM7fsc5xw@mail.gmail.com>
 <CAG1svNgixpxvq9v5QwzUPOT6odkx5osx2ZqPV-ypqgpHvSqxhg@mail.gmail.com>
 <CAJCQCtTt_Sf+Hzu=U3gpX9ONum1ykSqbMSGET4SLH6wdx2YAcg@mail.gmail.com>
 <acd820fd-6b48-4da8-a95c-eefe782fbe25@www.fastmail.com>
 <5c963491-947a-536c-ef8a-3aad62dc497e@redhat.com>
Message-ID: <CAJCQCtQ0NPh4xPbGL5z5QGadntjDn4D30Uia8bovGvQ+Fhpe8A@mail.gmail.com>

On Wed, Dec 15, 2021 at 4:09 AM Panu Matilainen <pmatilai at redhat.com> wrote:
>
> On 12/14/21 22:59, Colin Walters wrote:
> >
> >
> > On Thu, Dec 9, 2021, at 10:11 AM, Chris Murphy wrote:
> >
> >>> The change is not so simple. It is not only the movement of files from one location to another one. We store more types of data in that location - history database (sqlite), module failsafe data (yamls). In future we will store system state data (toml). Data is not only modified after RPM transactions but also by module and mark commands. What I want to say is that the change will be painful but in the proposal there are limited benefits.
> >
> > When the rpmdb was bdb and not extensible, I understand the idea of dnf having its own separate database.  But I don't understand why there are two separate sqlite databases now.
>
> The rpmdb is not hard-wired to sqlite. Also, whatever the format used
> it's strictly private to rpm except what's exposed through librpm APIs.
> So it's certainly NOT extensible in the sense that anybody wanting to
> put something package related there is free to do so.
>
> >
> > Anyways, a lot going on here and rather than point by point I'll say basically:
> >
> > It'd be great from the rpm-ostree PoV to have a shared consistent place for the rpmdb.  Last time this came up I think Panu really wanted to get the sqlite change out first, which - fair.  But now that's done, so are there any other blockers?
>
> Just the pain and misery of dealing with a fundamental change that has
> zero benefit to rpm itself. It'll be a long, long, long time before
> /var/lib/rpm is phased out of existence for good, and in the meanwhile
> us rpm f get to answer all the questions and complaints about it. I'm
> not looking forward to that.

The alternative to the proposal to switch rpmdb from /var to /usr, is
keeping it where it is. And provide matching between /usr and
/var/lib/rpm generations (or versions) by separate subvolume on Btrfs,
e.g. "varlibrpm" mounted at /var/lib/rpm. The separation is very cheap
on Btrfs, perhaps 200 KiB, because it's just a file btree. The cost is
a little more than a directory. And the snapshots only consume space
representing the difference between the snapshots.

However, for other implementations, such as  and separate file system
volumes for LVM+ext4 LVM+XFS or Stratis, it's not as cheap. Each
snapshot includes the file system journal, which varies in size.
Storage cost could be anywhere from 8 - 800 MiB per snapshot.

I'm not sure if the alternative is that great either, considering
movement is in progress to put rpmdb in /usr already.


--
Chris Murphy

From fweimer at redhat.com  Wed Dec 15 22:34:34 2021
From: fweimer at redhat.com (Florian Weimer)
Date: Wed, 15 Dec 2021 23:34:34 +0100
Subject: [Rpm-ecosystem] [Rpm-maint] RFC: Relocate RPM and DNF databases
 to /usr
In-Reply-To: <CAJCQCtQrKeZR6xM4bMwrM=sZhw+JZtcZtzd3VoLvEiM7fsc5xw@mail.gmail.com>
 (Chris Murphy's message of "Mon, 6 Dec 2021 23:00:44 -0500")
References: <CAJCQCtQrKeZR6xM4bMwrM=sZhw+JZtcZtzd3VoLvEiM7fsc5xw@mail.gmail.com>
Message-ID: <871r2dpked.fsf@oldenburg.str.redhat.com>

* Chris Murphy:

> Fedora 36 seems like a good time to do this. What do you think?

It's a bit odd to locate a database under /usr that isn't pre-built and
installed.  I guess in theory there could be systems with a read-only
/usr out there that still allow installation of packages into /opt.

Does it really help to improve the snapshot situation?  What about
software under /opt?  Maybe this needs multiple RPM databases
eventually, roughly aligned along file system boundaries.

Thanks,
Florian


From pmatilai at redhat.com  Thu Dec 16 08:33:22 2021
From: pmatilai at redhat.com (Panu Matilainen)
Date: Thu, 16 Dec 2021 10:33:22 +0200
Subject: [Rpm-ecosystem] RFC: Relocate RPM and DNF databases to /usr
In-Reply-To: <CAJCQCtQ0NPh4xPbGL5z5QGadntjDn4D30Uia8bovGvQ+Fhpe8A@mail.gmail.com>
References: <CAJCQCtQrKeZR6xM4bMwrM=sZhw+JZtcZtzd3VoLvEiM7fsc5xw@mail.gmail.com>
 <CAG1svNgixpxvq9v5QwzUPOT6odkx5osx2ZqPV-ypqgpHvSqxhg@mail.gmail.com>
 <CAJCQCtTt_Sf+Hzu=U3gpX9ONum1ykSqbMSGET4SLH6wdx2YAcg@mail.gmail.com>
 <acd820fd-6b48-4da8-a95c-eefe782fbe25@www.fastmail.com>
 <5c963491-947a-536c-ef8a-3aad62dc497e@redhat.com>
 <CAJCQCtQ0NPh4xPbGL5z5QGadntjDn4D30Uia8bovGvQ+Fhpe8A@mail.gmail.com>
Message-ID: <eba31324-933e-3795-e923-c320c98d5fd0@redhat.com>

On 12/15/21 23:08, Chris Murphy wrote:
> On Wed, Dec 15, 2021 at 4:09 AM Panu Matilainen <pmatilai at redhat.com> wrote:
>>
>> On 12/14/21 22:59, Colin Walters wrote:
>>>
>>>
>>> On Thu, Dec 9, 2021, at 10:11 AM, Chris Murphy wrote:
>>>
>>>>> The change is not so simple. It is not only the movement of files from one location to another one. We store more types of data in that location - history database (sqlite), module failsafe data (yamls). In future we will store system state data (toml). Data is not only modified after RPM transactions but also by module and mark commands. What I want to say is that the change will be painful but in the proposal there are limited benefits.
>>>
>>> When the rpmdb was bdb and not extensible, I understand the idea of dnf having its own separate database.  But I don't understand why there are two separate sqlite databases now.
>>
>> The rpmdb is not hard-wired to sqlite. Also, whatever the format used
>> it's strictly private to rpm except what's exposed through librpm APIs.
>> So it's certainly NOT extensible in the sense that anybody wanting to
>> put something package related there is free to do so.
>>
>>>
>>> Anyways, a lot going on here and rather than point by point I'll say basically:
>>>
>>> It'd be great from the rpm-ostree PoV to have a shared consistent place for the rpmdb.  Last time this came up I think Panu really wanted to get the sqlite change out first, which - fair.  But now that's done, so are there any other blockers?
>>
>> Just the pain and misery of dealing with a fundamental change that has
>> zero benefit to rpm itself. It'll be a long, long, long time before
>> /var/lib/rpm is phased out of existence for good, and in the meanwhile
>> us rpm f get to answer all the questions and complaints about it. I'm
>> not looking forward to that.
> 
> The alternative to the proposal to switch rpmdb from /var to /usr, is
> keeping it where it is. And provide matching between /usr and
> /var/lib/rpm generations (or versions) by separate subvolume on Btrfs,
> e.g. "varlibrpm" mounted at /var/lib/rpm. The separation is very cheap
> on Btrfs, perhaps 200 KiB, because it's just a file btree. The cost is
> a little more than a directory. And the snapshots only consume space
> representing the difference between the snapshots.
> 
> However, for other implementations, such as  and separate file system
> volumes for LVM+ext4 LVM+XFS or Stratis, it's not as cheap. Each
> snapshot includes the file system journal, which varies in size.
> Storage cost could be anywhere from 8 - 800 MiB per snapshot.
> 
> I'm not sure if the alternative is that great either, considering
> movement is in progress to put rpmdb in /usr already.

My grumbles aren't so much about rpmdb in /usr as a concept, it's the 
move of a very very long standing "well known location". Oh, Colin 
actually asked for blockers and I didn't mean this is a blocker, just an 
unpleasantness left to deal with. Sorry about that.

It'd minimize the pain somewhat if the db location was left at 
/var/lib/rpm on rpm level but /var/lib/rpm being a symlink pointing 
inside /usr until all active Fedora versions had this, and at that point 
changing the rpm configuration would make no difference to anybody 
(within Fedora). But such a construct almost certainly wont survive 
rpmdb rebuilds so it's probably not practical.

	- Panu -

> 
> 
> --
> Chris Murphy
> 


From walters at verbum.org  Thu Dec 16 14:41:44 2021
From: walters at verbum.org (Colin Walters)
Date: Thu, 16 Dec 2021 09:41:44 -0500
Subject: [Rpm-ecosystem] [Rpm-maint] RFC: Relocate RPM and DNF databases
 to /usr
In-Reply-To: <871r2dpked.fsf@oldenburg.str.redhat.com>
References: <CAJCQCtQrKeZR6xM4bMwrM=sZhw+JZtcZtzd3VoLvEiM7fsc5xw@mail.gmail.com>
 <871r2dpked.fsf@oldenburg.str.redhat.com>
Message-ID: <d78a86d6-afe4-4c50-b8d1-e8aaf8487204@www.fastmail.com>



On Wed, Dec 15, 2021, at 5:34 PM, Florian Weimer wrote:
> * Chris Murphy:
>
>> Fedora 36 seems like a good time to do this. What do you think?
>
> It's a bit odd to locate a database under /usr that isn't pre-built and
> installed.  

Why is that odd?  

> I guess in theory there could be systems with a read-only
> /usr out there that still allow installation of packages into /opt.
>
> Does it really help to improve the snapshot situation? 

Yes.  

I didn't wake up one day and say "hey you know what, today I'm going to move the rpm database just for fun".  Neither, for that matter did the OpenSUSE folks.  We haven't had this conversation over and over throughout the years just because it was some minor thing.

What I *did* wake up one day and say I'm going to do is make upgrades transactional and offline by default and hence safe.  No one should ever fear starting an operating system upgrade while their laptop is at 30% battery.  Administrators running important servers must be able to easily roll back when the kernel *or* systemd (or something) else regresses, because it's software, it regresses all the time despite our best efforts.

So yes again, this does matter.  And it matters because whether you're doing "image based upgrades" like ostree or just "client side offline updates" like the https://kubic.opensuse.org/documentation/man-pages/transactional-update.8.html thing - it's very important *what data specifically* is versioned/snapshotted and what isn't.  On an ostree system for example, it's completely normal that there are *two* rpm databases (one you're running, one that's pending in the new root).  

All the data in the rpmdb is about content that's in `/usr`.


> What about
> software under /opt? 

https://github.com/coreos/rpm-ostree/issues/233
Today indeed, rpm-ostree explicitly denies that.  Which, note we can do because we basically take over chunks of what librpm is doing on non-ostree systems.  But, it would be nice to drive some of this support into librpm too so it applies to non-ostree-but-snapshottable systems.


>  Maybe this needs multiple RPM databases
> eventually, roughly aligned along file system boundaries.

Yeah, that's one approach, though I would scope it really to just "/usr rpmdb" and "/usr/local" rpmdb - i.e. `/opt` and `/usr/local` are basically the same thing with different names.

From fweimer at redhat.com  Mon Dec 20 16:31:02 2021
From: fweimer at redhat.com (Florian Weimer)
Date: Mon, 20 Dec 2021 17:31:02 +0100
Subject: [Rpm-ecosystem] [Rpm-maint] RFC: Relocate RPM and DNF databases
 to /usr
In-Reply-To: <d78a86d6-afe4-4c50-b8d1-e8aaf8487204@www.fastmail.com> (Colin
 Walters's message of "Thu, 16 Dec 2021 09:41:44 -0500")
References: <CAJCQCtQrKeZR6xM4bMwrM=sZhw+JZtcZtzd3VoLvEiM7fsc5xw@mail.gmail.com>
 <871r2dpked.fsf@oldenburg.str.redhat.com>
 <d78a86d6-afe4-4c50-b8d1-e8aaf8487204@www.fastmail.com>
Message-ID: <874k73grw9.fsf@oldenburg.str.redhat.com>

* Colin Walters:

> On Wed, Dec 15, 2021, at 5:34 PM, Florian Weimer wrote:
>> * Chris Murphy:
>>
>>> Fedora 36 seems like a good time to do this. What do you think?
>>
>> It's a bit odd to locate a database under /usr that isn't pre-built and
>> installed.  
>
> Why is that odd?

Mentally, I still associate /usr with something that can be mounted
read-only from shared storage.

>> I guess in theory there could be systems with a read-only
>> /usr out there that still allow installation of packages into /opt.
>>
>> Does it really help to improve the snapshot situation? 
>
> Yes.  
>
> I didn't wake up one day and say "hey you know what, today I'm going
> to move the rpm database just for fun".  Neither, for that matter did
> the OpenSUSE folks.  We haven't had this conversation over and over
> throughout the years just because it was some minor thing.
>
> What I *did* wake up one day and say I'm going to do is make upgrades
> transactional and offline by default and hence safe.  No one should
> ever fear starting an operating system upgrade while their laptop is
> at 30% battery.  Administrators running important servers must be able
> to easily roll back when the kernel *or* systemd (or something) else
> regresses, because it's software, it regresses all the time despite
> our best efforts.

I appreciate these efforts.

Although transactional-update (as documented below) seems have one major
regression: transactional RPM updates now require reboots. 8-(

> So yes again, this does matter.  And it matters because whether you're
> doing "image based upgrades" like ostree or just "client side offline
> updates" like the
> https://kubic.opensuse.org/documentation/man-pages/transactional-update.8.html
> thing - it's very important *what data specifically* is
> versioned/snapshotted and what isn't.  On an ostree system for
> example, it's completely normal that there are *two* rpm databases
> (one you're running, one that's pending in the new root).
>
> All the data in the rpmdb is about content that's in `/usr`.

That totally ignores Software Collections and packages from ISVs.  If
the expected future that RPM is going to be an OS-internal software
deployment mechanism (and not be used for third-party software), it
should not be a side effect of this change, but an explicit decision.

Thanks,
Florian


From lists at colorremedies.com  Fri Dec 24 00:12:58 2021
From: lists at colorremedies.com (Chris Murphy)
Date: Thu, 23 Dec 2021 17:12:58 -0700
Subject: [Rpm-ecosystem] RFC: Relocate RPM and DNF databases to /usr
In-Reply-To: <eba31324-933e-3795-e923-c320c98d5fd0@redhat.com>
References: <CAJCQCtQrKeZR6xM4bMwrM=sZhw+JZtcZtzd3VoLvEiM7fsc5xw@mail.gmail.com>
 <CAG1svNgixpxvq9v5QwzUPOT6odkx5osx2ZqPV-ypqgpHvSqxhg@mail.gmail.com>
 <CAJCQCtTt_Sf+Hzu=U3gpX9ONum1ykSqbMSGET4SLH6wdx2YAcg@mail.gmail.com>
 <acd820fd-6b48-4da8-a95c-eefe782fbe25@www.fastmail.com>
 <5c963491-947a-536c-ef8a-3aad62dc497e@redhat.com>
 <CAJCQCtQ0NPh4xPbGL5z5QGadntjDn4D30Uia8bovGvQ+Fhpe8A@mail.gmail.com>
 <eba31324-933e-3795-e923-c320c98d5fd0@redhat.com>
Message-ID: <CAJCQCtSsuR_k1AL6HxoqRwDiscx_wbszyBn-trNUj7E2qqYRiA@mail.gmail.com>

Best I understand it, sounds like:
a. Split the RPM and DNF move to /usr, such that RPM move happens for
Fedora 36 and DNF move happens with DNF 5 ~Fedora 38;
b. Do not apply the RPM to /usr move on upgrades, only apply to new
clean installs;
c. there should be a symlink /var/lib/rpm -> /usr/lib/sysimage/rpm

I'm considering the pros and cons of just waiting until Fedora 38, or
such time as a Btrfs subvolume layout for transactional updates
(snapshot and rollback regime) is ready to be deployed, if earlier.
There doesn't seem to be a clear advantage of waiting.

Do rpm-ostree folks prefer to keep the symlink /usr/lib/sysimage/rpm
-> /usr/share/rpm or start directly using /usr/lib/sysimage/rpm? And
if so, any preference on when, in terms of Fedora releases?

--
Chris Murphy