ANNOUNCE: transactional updates for Tumbleweed

classic Classic list List threaded Threaded
45 messages Options
123
Reply | Threaded
Open this post in threaded view
|

ANNOUNCE: transactional updates for Tumbleweed

Thorsten Kukuk

Hello,

I would like to announce a new package in Tumbleweed: "transactional-update".

What is this, and why is this from interest for you?

Tumbleweed is a rolling release distribution. Which means, even
intrusive changes will be applied to a running system, which is
in use by the user.
For a lot of updates this is no problem, but sometimes there are
updates, which make trouble. Only remember the email from
Martin Wilk from Jan 16th, 2017: "CAREFUL: New Tumbleweed snapshot 20170112 released!". Or think about the pam-config update last year.

For another project I wrote a script updating a distribution in a
transactional way. I was asked by many people if I couldn't provide
that for Tumbleweed, too. So, here it is.

What are transactional updates?

A transactioan update:

- is atomic
  - The update does not influence your running system.
  - It's either successful applied or nothing is changed. So no broken
    RPMs are flying around in the system.
- can be rolled back
  - if the upgrade fails or if the update is not compatible, you can
    quickly restore the situation as it was before the upgrade.


What do you need to be able to use it?
- A recent installation of Tumbleweed (updating from older versions,
  especially installations made with openSUSE 13.x, will not work)
  with btrfs and snapshots enabled. If your installation is not
  recent enough, the script will tell and warn you and refuse to work.

How does it work?

In short, we create a snapshot of the system, update this snapshot,
do a "rollback" (or better "somersault") to this new snapshot and with
the next reboot, the updates are there. And if they don't work, boot
the old snapshot and continue to work, until the problem is fixed with
another update.

So, everything is fine?
No, it is not. The original project did work with a read-only root
filesystem. Which means, after taking the snapshot, the original data
couldn't be modified and no data could go lost. With Tumbleweed, all
changes you are doing to the root filesystem subvolume after starting
the script will be lost with the next reboot into the new snapshot.
Which means, after running the script, you should immeaditly reboot
to activate the changes and avoid data lossage.
Modifications in other subvolumes are fine.

Another problem is: we are using snapshots and rollback, so face the
same issues as with snapshots and rollback.
I have run this script now for three month on a default Tumbleweed
installation by cron without any problems. But there are RPMs, which
will create problems, and which needs to be adjusted.
1. strictly seperate code from user data. /srv is a real nightmare.
   Either user data will go lost, or the application will not be
   updated or rolled back.
2. Don't modify data in post install sections, but during boot or
   first start instead. If the data is in a subvolume, this one will
   not be accessible during the upgrade. Or the update wouldn't be
   atomic anymore.
3. Don't create something outside the snapshot subvolume, this
   will not survive the next reboot.
4. RPM, which installs directories or data into directories, which
   are subvolumes, needs to be adjusted. This will not work.
   Example: /var/cache is an own subvolume. Quite some RPMs
   create directories and data there, and some of them will stop
   working if you remove this directories.
   That's bad even without transactional updates, a system
   administrator should always be allowed to delete the cache.
   A better way is to create the directories during boot with
   tmpfiles.d(5).
   Same problem for all other subvolumes like /var/log, /var/spool,
   etc.

So, now you can test the script and I hope it is from use for many
of you. I'm pretty sure there are still situations which the script
cannot handle, and a lot of you have ideas about how to improve it.
I'm happy about every patch or idea. And of course adjusted RPMs,
which have no problem with this update method.

  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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: ANNOUNCE: transactional updates for Tumbleweed

opensuse.lietuviu.kalba
2017.01.21 15:46, Thorsten Kukuk rašė:
> Hello,
>
> I would like to announce a new package in Tumbleweed: "transactional-update".

Nice idea! But for installation of critical packages, maybe would be
better to use this schema:

1) just download critical RPMs (don't install emediately);

2) at next reboot (or re-login, depending on situation), at early stage
of boot, do installation of thees RPMs;

3) if necessary automatically reboot again.

I believe this schema can work not only for BTRFS filesystem (with
snapshoots), but also with reliable EXT4 (that don't support snapshots).

This is just idea to enhence situation. Maybe "transactional-update"
could benefit from it in case of problematic packages.

--

Regards

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: ANNOUNCE: transactional updates for Tumbleweed

Thorsten Kukuk
On Sat, Jan 21, opensuse.lietuviu.kalba wrote:

> 2017.01.21 15:46, Thorsten Kukuk rašė:
> > Hello,
> >
> > I would like to announce a new package in Tumbleweed: "transactional-update".
>
> Nice idea! But for installation of critical packages, maybe would be better
> to use this schema:
>
> 1) just download critical RPMs (don't install emediately);
>
> 2) at next reboot (or re-login, depending on situation), at early stage of
> boot, do installation of thees RPMs;

That's what windows is doing. The disadvantage is, that your machine
is blocked until all updates are installed. And that had already
really bad ramifications for some people (I will bring examples at FOSDEM).
This is exactly what we don't want.

And, as I wrote, the original project is using a read-only filesystem,
where your idea would not work at all.

  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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: ANNOUNCE: transactional updates for Tumbleweed

Thorsten Kukuk
On Sat, Jan 21, Thorsten Kukuk wrote:

> On Sat, Jan 21, opensuse.lietuviu.kalba wrote:
>
> > 2017.01.21 15:46, Thorsten Kukuk rašė:
> > > Hello,
> > >
> > > I would like to announce a new package in Tumbleweed: "transactional-update".
> >
> > Nice idea! But for installation of critical packages, maybe would be better
> > to use this schema:
> >
> > 1) just download critical RPMs (don't install emediately);
> >
> > 2) at next reboot (or re-login, depending on situation), at early stage of
> > boot, do installation of thees RPMs;
>
> That's what windows is doing. The disadvantage is, that your machine
> is blocked until all updates are installed. And that had already
> really bad ramifications for some people (I will bring examples at FOSDEM).
> This is exactly what we don't want.

I forgot two other disadvantages of your approach:
1. updates are not atomic, if a patch couldn't be applied correct, your
   system will be in an undefined state.
2. it will not help at all for problems like the incompatible pam-config
   update, from which you cannot recover with your idea.

> And, as I wrote, the original project is using a read-only filesystem,
> where your idea would not work at all.
>
>   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: [hidden email]
> To contact the owner, e-mail: [hidden email]

--
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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: ANNOUNCE: transactional updates for Tumbleweed

Andrei Borzenkov
In reply to this post by opensuse.lietuviu.kalba
21.01.2017 17:53, opensuse.lietuviu.kalba пишет:

> 2017.01.21 15:46, Thorsten Kukuk rašė:
>> Hello,
>>
>> I would like to announce a new package in Tumbleweed:
>> "transactional-update".
>
> Nice idea! But for installation of critical packages, maybe would be
> better to use this schema:
>
> 1) just download critical RPMs (don't install emediately);
>
> 2) at next reboot (or re-login, depending on situation), at early stage
> of boot, do installation of thees RPMs;
>
> 3) if necessary automatically reboot again.
>

This is supported by PackageKit for quite some time already

https://www.freedesktop.org/wiki/Software/systemd/SystemUpdates/

> I believe this schema can work not only for BTRFS filesystem (with
> snapshoots), but also with reliable EXT4 (that don't support snapshots).
>
> This is just idea to enhence situation. Maybe "transactional-update"
> could benefit from it in case of problematic packages.
>

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: ANNOUNCE: transactional updates for Tumbleweed

Andrei Borzenkov
In reply to this post by Thorsten Kukuk
21.01.2017 16:46, Thorsten Kukuk пишет:
> 4. RPM, which installs directories or data into directories, which
>    are subvolumes, needs to be adjusted. This will not work.

Why? Solaris Live Update supports it for ages. It builds environment
that includes any arbitrary filesystem (you define). So it's not "this
will not work" but "this is not implemented".

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: ANNOUNCE: transactional updates for Tumbleweed

Thorsten Kukuk
On Sat, Jan 21, Andrei Borzenkov wrote:

> 21.01.2017 16:46, Thorsten Kukuk пишет:
> > 4. RPM, which installs directories or data into directories, which
> >    are subvolumes, needs to be adjusted. This will not work.
>
> Why? Solaris Live Update supports it for ages. It builds environment
> that includes any arbitrary filesystem (you define). So it's not "this
> will not work" but "this is not implemented".

How does Solaris Live Update merge a Postgresql7 database with a
Postgresql8 database, for example? Would be really interesting to
know ...

  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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: ANNOUNCE: transactional updates for Tumbleweed

Andrei Borzenkov
21.01.2017 19:55, Thorsten Kukuk пишет:

> On Sat, Jan 21, Andrei Borzenkov wrote:
>
>> 21.01.2017 16:46, Thorsten Kukuk пишет:
>>> 4. RPM, which installs directories or data into directories, which
>>>    are subvolumes, needs to be adjusted. This will not work.
>>
>> Why? Solaris Live Update supports it for ages. It builds environment
>> that includes any arbitrary filesystem (you define). So it's not "this
>> will not work" but "this is not implemented".
>
> How does Solaris Live Update merge a Postgresql7 database with a
> Postgresql8 database, for example?

It does not because it is out of its scope. What it does is install
packages. If data that is managed by package binaries is incompatible
with new version of binaries, you cannot convert it during package
installation anyway - this has to be deferred until some later point in
time when new binary is run for the first time.

I read your quoted statement as "package cannot contain files from
different subvolumes/filesystems". Now, *that* I cannot agree with -
nothing prevents you from cloning these subvolumes, building new version
of boot environment that includes all these clones and switching to it
on reboot. Whether this is feasible in each particular case, is separate
question.

> Would be really interesting to
> know ...
>
>   Thorsten
>

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: ANNOUNCE: transactional updates for Tumbleweed

Bruno Friedmann-2
In reply to this post by Thorsten Kukuk
On samedi, 21 janvier 2017 14.46:19 h CET Thorsten Kukuk wrote:

> 4. RPM, which installs directories or data into directories, which
>    are subvolumes, needs to be adjusted. This will not work.
>    Example: /var/cache is an own subvolume. Quite some RPMs
>    create directories and data there, and some of them will stop
>    working if you remove this directories.
>    That's bad even without transactional updates, a system
>    administrator should always be allowed to delete the cache.
>    A better way is to create the directories during boot with
>    tmpfiles.d(5).
>    Same problem for all other subvolumes like /var/log, /var/spool,
>    etc.

I've some difficulties to understand why it's bad ?
I want to have my squid cache stored and stay on disk so it's persitant.
Same apply for zypper If I want to keep packages ...


--

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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: ANNOUNCE: transactional updates for Tumbleweed

Thorsten Kukuk
In reply to this post by Andrei Borzenkov

Hi,

On Sat, Jan 21, Andrei Borzenkov wrote:

> It does not because it is out of its scope. What it does is install
> packages. If data that is managed by package binaries is incompatible
> with new version of binaries, you cannot convert it during package
> installation anyway - this has to be deferred until some later point in
> time when new binary is run for the first time.

Ok, so that's exactly what I wrote initial, too.

> I read your quoted statement as "package cannot contain files from
> different subvolumes/filesystems". Now, *that* I cannot agree with -
> nothing prevents you from cloning these subvolumes, building new version
> of boot environment that includes all these clones and switching to it
> on reboot. Whether this is feasible in each particular case, is separate
> question.

Looks like Solaris ZFS can handle different subvolumes as one. btrfs
does not have this feature, but it wouldn't help in this case, too.

We do create the subvolumes on purpose. Either they contain high volatile
data (e.g. /var/cache), or they contain data you don't want to loose
during update or rollback (var/lib/pgsql, /var/spool/mail).
And I'm speaking about this subvolumes: an RPM should not contain
data which is in the "main" root subvolume, and a "data" subvolume.
Either you will have data lossage on update or rollback, or you have
inconsistent RPMs (the changes in a "data" subvolume are missing after
reboot.

  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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: ANNOUNCE: transactional updates for Tumbleweed

Thorsten Kukuk
In reply to this post by Bruno Friedmann-2
On Sat, Jan 21, Bruno Friedmann wrote:

> On samedi, 21 janvier 2017 14.46:19 h CET Thorsten Kukuk wrote:
> > 4. RPM, which installs directories or data into directories, which
> >    are subvolumes, needs to be adjusted. This will not work.
> >    Example: /var/cache is an own subvolume. Quite some RPMs
> >    create directories and data there, and some of them will stop
> >    working if you remove this directories.
> >    That's bad even without transactional updates, a system
> >    administrator should always be allowed to delete the cache.
> >    A better way is to create the directories during boot with
> >    tmpfiles.d(5).
> >    Same problem for all other subvolumes like /var/log, /var/spool,
> >    etc.
>
> I've some difficulties to understand why it's bad ?
> I want to have my squid cache stored and stay on disk so it's persitant.
> Same apply for zypper If I want to keep packages ...

Assume e.g. you want to cleanup your disk because you are running out
of disk space.
And this is a requirement of the FHS, too: An admin should always be
allowed to delete the cache and applications should be able to handle
that.

  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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: ANNOUNCE: transactional updates for Tumbleweed

Bruno Friedmann-2
On dimanche, 22 janvier 2017 10.56:46 h CET Thorsten Kukuk wrote:

> On Sat, Jan 21, Bruno Friedmann wrote:
> > On samedi, 21 janvier 2017 14.46:19 h CET Thorsten Kukuk wrote:
> > > 4. RPM, which installs directories or data into directories, which
> > >
> > >    are subvolumes, needs to be adjusted. This will not work.
> > >    Example: /var/cache is an own subvolume. Quite some RPMs
> > >    create directories and data there, and some of them will stop
> > >    working if you remove this directories.
> > >    That's bad even without transactional updates, a system
> > >    administrator should always be allowed to delete the cache.
> > >    A better way is to create the directories during boot with
> > >    tmpfiles.d(5).
> > >    Same problem for all other subvolumes like /var/log, /var/spool,
> > >    etc.
> >
> > I've some difficulties to understand why it's bad ?
> > I want to have my squid cache stored and stay on disk so it's persitant.
> > Same apply for zypper If I want to keep packages ...
>
> Assume e.g. you want to cleanup your disk because you are running out
> of disk space.
> And this is a requirement of the FHS, too: An admin should always be
> allowed to delete the cache and applications should be able to handle
> that.
>
>   Thorsten

The inside of (I'm still using a real example) of /var/cache/squid can be
cleaned at any time by the administrator. And the actual systemd service file
will handle according to the configuration the rebuild of cache hierachy.

But /var/cache/squid has to be owned by someone so it can be cleanup in case
of removal of squid package.

Seem to what I understand from you point of view, is that we should have a
%ghost /var/cache/squid in %files section and then a squid.conf in /usr/lib/
tempfiles.d that create this directory if not existing on boot.

Did I understand your proposal when translated to real package ?


--

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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: ANNOUNCE: transactional updates for Tumbleweed

Thorsten Kukuk
On Sun, Jan 22, Bruno Friedmann wrote:

> But /var/cache/squid has to be owned by someone so it can be cleanup in case
> of removal of squid package.

And that is an error in reasoning: /var/cache/squid will not be deleted
if you deinstall squid, because this directory would still contain files.
So after deinstallation of squid, if you have a directory /var/cache/squid
which is not owned by any package. That the package was formerly owned
by squid does not help you in any way, except if you did never configure
and run squid. It is only helpful as long as the package is installed.
(Which does not mean I'm in favour of removing this directory from the
packagelist, only the reason why it is important for de-installation
is wrong).

> Seem to what I understand from you point of view, is that we should have a
> %ghost /var/cache/squid in %files section and then a squid.conf in /usr/lib/
> tempfiles.d that create this directory if not existing on boot.
>
> Did I understand your proposal when translated to real package ?

Yes, this is what I mean.

  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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: ANNOUNCE: transactional updates for Tumbleweed

Vojtěch Zeisek-2
Dne neděle 22. ledna 2017 12:00:19 CET, Thorsten Kukuk napsal(a):

> On Sun, Jan 22, Bruno Friedmann wrote:
> > But /var/cache/squid has to be owned by someone so it can be cleanup in
> > case of removal of squid package.
>
> And that is an error in reasoning: /var/cache/squid will not be deleted
> if you deinstall squid, because this directory would still contain files.
> So after deinstallation of squid, if you have a directory /var/cache/squid
> which is not owned by any package. That the package was formerly owned
> by squid does not help you in any way, except if you did never configure
> and run squid. It is only helpful as long as the package is installed.
> (Which does not mean I'm in favour of removing this directory from the
> packagelist, only the reason why it is important for de-installation
> is wrong).
May I ask how such cleanup should be done after removal of the package? I'm
sorry, I'm bit confused. And little bit moving it into philosophy: generally,
if I uninstall something and after some time I install it back. Should I start
with empty settings or continue where I interrupted usage of that software
(configuration as well as data?.

Generally, I like the idea, it seems to be very robust method. Do I understand
it correctly, that as soon as I continue work in userpsace (e.g. with browser
or office application), I can safely postpone reboot? But what about
applications writing something into /tmp?

--
Vojtěch Zeisek

Komunita openSUSE GNU/Linuxu
Community of the openSUSE GNU/Linux

https://www.opensuse.org/
https://trapa.cz/

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: ANNOUNCE: transactional updates for Tumbleweed

Carlos E. R.-2
On 2017-01-22 12:59, Vojtěch Zeisek wrote:
> May I ask how such cleanup should be done after removal of the package? I'm
> sorry, I'm bit confused. And little bit moving it into philosophy: generally,
> if I uninstall something and after some time I install it back. Should I start
> with empty settings or continue where I interrupted usage of that software
> (configuration as well as data?.

The behaviour in SuSE/openSUSE since I know it is to leave the data and
configuration intact. The installation/removal/upgrade by rpm only
touches the code. And also the config, but never replacing it fully:
sometimes the new config is activated, sometimes the old. Both versions
are in place, one renamed.

Actually an rpm feature.

--
Cheers / Saludos,

                Carlos E. R.
                (from 42.2 x86_64 "Malachite" at Telcontar)


signature.asc (188 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: ANNOUNCE: transactional updates for Tumbleweed

Thorsten Kukuk
In reply to this post by Vojtěch Zeisek-2
On Sun, Jan 22, Vojtěch Zeisek wrote:

> Generally, I like the idea, it seems to be very robust method. Do I understand
> it correctly, that as soon as I continue work in userpsace (e.g. with browser
> or office application), I can safely postpone reboot? But what about
> applications writing something into /tmp?

You can postpone the reboot to any time you want. But the risk
increases that changes to the root subvolume are made, which will
go lost.
Applications writing to /tmp should not expect that this will
survive a reboot. Quite the opposite, data in /tmp is defined as
not surviving a reboot. But since /tmp is a subvolume, it is no
problem in this case.
But writing to e.g. /etc is a problem.

  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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: ANNOUNCE: transactional updates for Tumbleweed

Vojtěch Zeisek-2
In reply to this post by Carlos E. R.-2
Dne neděle 22. ledna 2017 13:15:17 CET, Carlos E. R. napsal(a):

> On 2017-01-22 12:59, Vojtěch Zeisek wrote:
> > May I ask how such cleanup should be done after removal of the package?
> > I'm sorry, I'm bit confused. And little bit moving it into philosophy:
> > generally, if I uninstall something and after some time I install it
> > back. Should I start with empty settings or continue where I interrupted
> > usage of that software (configuration as well as data?.
>
> The behaviour in SuSE/openSUSE since I know it is to leave the data and
> configuration intact. The installation/removal/upgrade by rpm only
> touches the code. And also the config, but never replacing it fully:
> sometimes the new config is activated, sometimes the old. Both versions
> are in place, one renamed.
OK. As far as I know it is not possible to force cleanup of such data/
configuration files when removing package. Correct? Wouldn't it be nice to have
such option when using zypper? I hope I don't hitchhike the thread too much...

--
Vojtěch Zeisek

Komunita openSUSE GNU/Linuxu
Community of the openSUSE GNU/Linux

https://www.opensuse.org/
https://trapa.cz/

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: ANNOUNCE: transactional updates for Tumbleweed

Dominique Leuenberger / DimStar
In reply to this post by opensuse.lietuviu.kalba
On Sat, 2017-01-21 at 16:53 +0200, opensuse.lietuviu.kalba wrote:

> 2017.01.21 15:46, Thorsten Kukuk rašė:
> > Hello,
> >
> > I would like to announce a new package in Tumbleweed:
> > "transactional-update".
>
> Nice idea! But for installation of critical packages, maybe would be 
> better to use this schema:
>
> 1) just download critical RPMs (don't install emediately);
>
> 2) at next reboot (or re-login, depending on situation), at early
> stage 
> of boot, do installation of thees RPMs;
>
> 3) if necessary automatically reboot again.
>
> I believe this schema can work not only for BTRFS filesystem (with 
> snapshoots), but also with reliable EXT4 (that don't support
> snapshots).
>
> This is just idea to enhence situation. Maybe "transactional-update" 
> could benefit from it in case of problematic packages.
This is already possible - using the so-called offline update method
(probably undertested)

pkcon update -d # download available updates)
pkcon offline-trigger # Set system to boot to offline-update on next
boot

If you use GNOME Software to update your system, this is also exactly
what is happening behind the curtains.

It has the advantage of being in a 'minimal running system where only
few things can go wrong' (but still can go wrong so far) - and it has
the disadvantage that it applies updates when you are booting or
restarting.

The transactional update method surely has its merits over the offline-
update method in the fact that the user does not have to wait for the
update during boot... with the negative effects as described by
Thorsten.

Cheers,
Dominique

signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: ANNOUNCE: transactional updates for Tumbleweed

Johannes Kastl-2
In reply to this post by Vojtěch Zeisek-2
On 23.01.17 08:27 Vojtěch Zeisek wrote:

> OK. As far as I know it is not possible to force cleanup of such
> data/ configuration files when removing package. Correct? Wouldn't
> it be nice to have such option when using zypper?

How to distinguish between deinstallation and deinstallation before
installing the newer version of the package? Could be tricky...

Johannes



signature.asc (252 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: ANNOUNCE: transactional updates for Tumbleweed

Vojtěch Zeisek-2
Dne pondělí 23. ledna 2017 11:03:08 CET, Johannes Kastl napsal(a):
> On 23.01.17 08:27 Vojtěch Zeisek wrote:
> > OK. As far as I know it is not possible to force cleanup of such
> > data/ configuration files when removing package. Correct? Wouldn't
> > it be nice to have such option when using zypper?
>
> How to distinguish between deinstallation and deinstallation before
> installing the newer version of the package? Could be tricky...

Yes, so what about optional parameter to do so?

--
Vojtěch Zeisek

Komunita openSUSE GNU/Linuxu
Community of the openSUSE GNU/Linux

https://www.opensuse.org/
https://trapa.cz/

signature.asc (849 bytes) Download Attachment
123