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
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
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
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
> 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
between two reboots, and the plugin is running
pre-upgrade code. This code would then invoke post-upgrade rpm. It's
certainly doable, but seems a bit funky.
Right, requiring changes to previous versions is not okay. I seem to
be thinking our upgrade tooling had gotten fixed at some poi
the upgrade plugins run code is in
> >>>>> upgrade phase between two reboots, and the plugin is running
> >>>>> pre-upgrade code. This code would then invoke post-upgrade rpm. It's
> >>>>> certainly doable, but seems a bit funky.
&
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
x27;s
certainly doable, but seems a bit funky.
Right, requiring changes to previous versions is not okay. I seem to
be thinking our upgrade tooling had gotten fixed at some point to
perform the upgrade on the target distro packaging management stack
as it would really need to be, but guess that was j
n invoke post-upgrade rpm. It's
> >>> certainly doable, but seems a bit funky.
> >>
> >>Right, requiring changes to previous versions is not okay. I seem to
> >>be thinking our upgrade tooling had gotten fixed at some point to
> >>perform the
vious versions is not okay. I seem to
be thinking our upgrade tooling had gotten fixed at some point to
perform the upgrade on the target distro packaging management stack
as it would really need to be, but guess that was just a dream.
Relying on the target distro management stack sound nice, b
g our upgrade tooling had gotten fixed at some point to
perform the upgrade on the target distro packaging management stack
as it would really need to be, but guess that was just a dream.
Relying on the target distro management stack sound nice, but is
actually problematic: how do you run the
12 matches
Mail list logo
