Re: Upgrade tooling

2020-03-31 Thread Matthew Miller
On Mon, Mar 30, 2020 at 10:13:19AM +0300, Panu Matilainen wrote: > strategy into RHEL world, people could only start using file > triggers and rich dependencies in RHEL and EPEL 9 which I can only > assume will be released some year in the future. Think about that > for a while. For what it's wort

Re: Upgrade tooling (was: Re: Fedora 33 System-Wide Change proposal: Sqlite RpmDB)

2020-03-31 Thread Zbigniew Jędrzejewski-Szmek
On Mon, Mar 30, 2020 at 02:40:03PM +0200, Miroslav Suchý wrote: > Dne 27. 03. 20 v 8:55 Zbigniew Jędrzejewski-Szmek napsal(a): > > In current "offline upgrade" scheme, the upgrade > > tools are running on the real system, with udev active. > This thread has mostly died, but I didn't want to leav

Re: Upgrade tooling

2020-03-30 Thread Panu Matilainen
On 3/30/20 3:00 PM, Nicolas Mailhot via devel wrote: On 3/28/20 8:59 AM, Zbigniew Jędrzejewski-Szmek wrote: Yes, that is an important hurdle that Fedora generally doesn't encounter at all. Fedora usually waits until the new rpm functionality is released in older versions of Fedora before allo

Re: Upgrade tooling (was: Re: Fedora 33 System-Wide Change proposal: Sqlite RpmDB)

2020-03-30 Thread Miroslav Suchý
Dne 27. 03. 20 v 8:55 Zbigniew Jędrzejewski-Szmek napsal(a): > In current "offline upgrade" scheme, the upgrade > tools are running on the real system, with udev active. How the "offline upgrade" works under hood? Do I understand correctly that even "offline ugprade" will have problem with upgra

Re: Upgrade tooling

2020-03-30 Thread Nicolas Mailhot via devel
> On 3/28/20 8:59 AM, Zbigniew Jędrzejewski-Szmek wrote: > > > > Yes, that is an important hurdle that Fedora generally doesn't > > encounter > > at all. Fedora usually waits until the new rpm functionality is > > released > > in older versions of Fedora before allowing it to be used in > > rawhi

Re: Upgrade tooling

2020-03-30 Thread Panu Matilainen
On 3/28/20 8:59 AM, Zbigniew Jędrzejewski-Szmek wrote: On Fri, Mar 27, 2020 at 10:34:49AM +0200, Panu Matilainen wrote: On 3/27/20 9:55 AM, Zbigniew Jędrzejewski-Szmek wrote: On Fri, Mar 27, 2020 at 09:04:53AM +0200, Panu Matilainen wrote: On 3/26/20 2:35 PM, Zbigniew Jędrzejewski-Szmek wrote:

Re: Upgrade tooling

2020-03-28 Thread Zbigniew Jędrzejewski-Szmek
On Fri, Mar 27, 2020 at 10:34:49AM +0200, Panu Matilainen wrote: > On 3/27/20 9:55 AM, Zbigniew Jędrzejewski-Szmek wrote: > >On Fri, Mar 27, 2020 at 09:04:53AM +0200, Panu Matilainen wrote: > >>On 3/26/20 2:35 PM, Zbigniew Jędrzejewski-Szmek wrote: > >>>On Thu, Mar 26, 2020 at 02:00:49PM +0200, Pan

Re: Upgrade tooling (was: Re: Fedora 33 System-Wide Change proposal: Sqlite RpmDB)

2020-03-27 Thread Chris Murphy
On Fri, Mar 27, 2020 at 1:56 AM Zbigniew Jędrzejewski-Szmek wrote: > > Where would mock be executing from? The same filesystem it is modifying? > Somehow it seems that this doesn't change much, but just brings > in another layer. Or will a complete copy of the system be made in > memory to execute

Re: Upgrade tooling

2020-03-27 Thread Panu Matilainen
On 3/27/20 9:55 AM, Zbigniew Jędrzejewski-Szmek wrote: On Fri, Mar 27, 2020 at 09:04:53AM +0200, Panu Matilainen wrote: On 3/26/20 2:35 PM, Zbigniew Jędrzejewski-Szmek wrote: On Thu, Mar 26, 2020 at 02:00:49PM +0200, Panu Matilainen wrote: previous-release-blocker(s) and previous-previous-r

Re: Upgrade tooling (was: Re: Fedora 33 System-Wide Change proposal: Sqlite RpmDB)

2020-03-27 Thread Zbigniew Jędrzejewski-Szmek
On Fri, Mar 27, 2020 at 09:04:53AM +0200, Panu Matilainen wrote: > On 3/26/20 2:35 PM, Zbigniew Jędrzejewski-Szmek wrote: > >On Thu, Mar 26, 2020 at 02:00:49PM +0200, Panu Matilainen wrote: > >>> previous-release-blocker(s) and previous-previous-release-blockers(s), > >>> since the changes woul

Re: Upgrade tooling

2020-03-27 Thread Panu Matilainen
On 3/27/20 9:04 AM, Panu Matilainen wrote: On 3/26/20 2:35 PM, Zbigniew Jędrzejewski-Szmek wrote: On Thu, Mar 26, 2020 at 02:00:49PM +0200, Panu Matilainen wrote:    previous-release-blocker(s) and previous-previous-release-blockers(s),    since the changes would need to be deployed in F32 and