Dear Tumbleweed users and hackers,
A steady flow of snapshots is reaching the Tumbleweed users: this week, another 4 snapshots have been released onto the users, some with a bit more bandwidth demand, some with issues that were not anticipated by the test suite (but easily resolved by the user, and fixes underway) The week saw releases of the snapshot 0110, 0114, 0116 and 0117, with those changes: * mpfr 4.0: as announced last week, we needed an almost complete rebuild of the distro, as this is deeply nested. This resulted in snapshot 0110 being larger than average. * Squid 4.0.22 (upgraded from 3.5.27) * RPM 4.14. Caution for packagers: rpm is less forgiving on errors in spec files * Bind 9.11.2 * Mesa 17.3.2: in order to improve the distro build performance, Meas was split into two parts to be built. Users that updated their system using “–no-recommends” did not get Mesa-dri auto-installed, resulting in the graphical system possibly not starting up. Simply install Mesa- dri for now manually (dependency chain fixes are underway) * Linux kernel 4.14.13 * librsvg 2.42.0: rewritten in Rust * OpenSSH 7.6p1 * KDE Applications 17.12.1 * Default firewall module picked for new installs is now firewalld * Last, but not least: libstorage-ng has arrived But, Tumbleweed would not be rolling if no further things would be in the works already. The larger topics are: * Glibc will completely drop sunrpc support (we have tirpc available, with ipv6 support) * Linux kernel 4.14.14 * Change of default Ruby version from 2.4 to 2.5 * KDE Frameworks 5.42.0 * KDE Plasma 5.12.0 The list of work in progress feels quite short compared to what has been achieved last week, but keep in mind that some things have been in the works for quite a while, it was just coincidence that so many things turned out ready at the same time. Cheers, Dominique |
> The week saw releases of the snapshot 0110, 0114, 0116 and 0117, with
> those changes: > > * mpfr 4.0: as announced last week, we needed an almost complete > rebuild of the distro, as this is deeply nested. This resulted in > snapshot 0110 being larger than average. > * Squid 4.0.22 (upgraded from 3.5.27) > * RPM 4.14. Caution for packagers: rpm is less forgiving on errors in > spec files > * Bind 9.11.2 > * Mesa 17.3.2: in order to improve the distro build performance, Meas > was split into two parts to be built. Users that updated their system > using “–no-recommends” did not get Mesa-dri auto-installed, resulting > in the graphical system possibly not starting up. Simply install Mesa- > dri for now manually (dependency chain fixes are underway) > * Linux kernel 4.14.13 > * librsvg 2.42.0: rewritten in Rust > * OpenSSH 7.6p1 > * KDE Applications 17.12.1 > * Default firewall module picked for new installs is now firewalld > * Last, but not least: libstorage-ng has arrived I would also like to add that snapshot 0117 introduced the new btrfs default subvolume layout Any fresh installation of Tumbleweed using the default btrfs root filesystem will no longer have multiple subvolumes under /var (eg /var/lib/mysql, /var/cache, etc) and instead have a single unified /var subvolume. This simplifies snapshots and rollbacks, will prevent accidental dataloss on rollback for any user data held in /var, and improve performance of any database or VM images that are held in /var as all of /var also now has Copy-on-Write disabled by default. It's also particularly useful for openSUSE Kubic which was struggling with the consequences of much of /var being read-only as it was considered part of Kubic's read-only root filesystem. Formerly important system data that was located in /var is now available in /usr. In particular rpm's database has moved from /var/lib/rpmdb to /usr/lib/sysimage/rpm (with backwards compatible symlinks in place), and /var/adm/fillup-templates now should be located in /usr/share/fillup-templates. If we've missed any important system data that is still in /var but needs to be contained in a system snapshot, please contact me urgently so we can address it's relocation from /var ASAP. Packagers can expect rpmlint rules to prevent the storing of files in /var/adm/fillup-templates in one of Tumbleweed's snapshots next week. We will not be automatically moving user data from the old structure to the new one, but I'm open to any suggestions on how to script it if anyone has any bright ideas. -- To unsubscribe, e-mail: [hidden email] To contact the owner, e-mail: [hidden email] |
In reply to this post by Dominique Leuenberger / DimStar
* Dominique Leuenberger / DimStar <[hidden email]> [01-20-18 07:19]:
> Dear Tumbleweed users and hackers, > > A steady flow of snapshots is reaching the Tumbleweed users: this week, > another 4 snapshots have been released onto the users, some with a bit > more bandwidth demand, some with issues that were not anticipated by > the test suite (but easily resolved by the user, and fixes underway) > > The week saw releases of the snapshot 0110, 0114, 0116 and 0117, with > those changes: [...] > * Default firewall module picked for new installs is now firewalld when will SuSEfirewall2 be migrated to the new firewalld? tks, -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: [hidden email] To contact the owner, e-mail: [hidden email] |
Il 20/01/2018 10:51, Patrick Shanahan ha scritto:
> * Dominique Leuenberger / DimStar <[hidden email]> [01-20-18 07:19]: >> Dear Tumbleweed users and hackers, >> >> A steady flow of snapshots is reaching the Tumbleweed users: this week, >> another 4 snapshots have been released onto the users, some with a bit >> more bandwidth demand, some with issues that were not anticipated by >> the test suite (but easily resolved by the user, and fixes underway) >> >> The week saw releases of the snapshot 0110, 0114, 0116 and 0117, with >> those changes: > [...] >> * Default firewall module picked for new installs is now firewalld > > when will SuSEfirewall2 be migrated to the new firewalld? > > tks, > custom rules and settings? The firewalld migration is/will be mandatory/silent or could be decided by the user? Thanks and regards, -- Marco Calistri Linux version : openSUSE Tumbleweed 20180116 Kernel: 4.14.14-1.geef6178-default - Cinnamon 3.6.7 -- To unsubscribe, e-mail: [hidden email] To contact the owner, e-mail: [hidden email] |
In reply to this post by Dominique Leuenberger / DimStar
On 01/20/2018 01:16 PM, Dominique Leuenberger / DimStar wrote:
> * librsvg 2.42.0: rewritten in Rust This is actually a huge change as librsvg is a core library with a large number of reverse dependencies now partially written in a programming language with limited architecture support. Please note that Rust upstream still considers only x86_64/_32 to be tier 1 targets, all other architectures are merely considered tier 2 or less which means that the Rust compiler is not guaranteed to produce working code, meaning that one update of the Rust compiler or librsvg may result in librsvg and potentially the many packages depending on it to stop working. Furthermore, this change limits the bootstrappability of openSUSE to the architectures supported by the Rust compiler. If, for example, the community would decide to support RISC-V, it would not be possible as the Rust compiler doesn't support that particular architecture at the moment although I have heard that there are ongoing efforts. Finally, one problem with Rust that I ran into when working on the Rust compiler code itself is the high volatility of the language and the code. Things that used to build fine with Rust 1.19 would break with 1.20 and so on. From a distribution maintainer's point of view, this can be very tedious and annoying. Overall, I think the move to memory-safe languages is generally a good idea. However, I'm still a bit worried with the move to Rust as I think the language isn't yet as stable as it should be for writing core libraries in it. Adrian -- To unsubscribe, e-mail: [hidden email] To contact the owner, e-mail: [hidden email] |
On 2018-01-20, John Paul Adrian Glaubitz <[hidden email]> wrote:
> This is actually a huge change as librsvg is a core library with a large > number of reverse dependencies now partially written in a programming > language with limited architecture support. Yes, I agree this is a problem -- maybe we should keep around an old version of librsvg purely for "tier 2" architecture support? > Finally, one problem with Rust that I ran into when working on the > Rust compiler code itself is the high volatility of the language and the > code. Things that used to build fine with Rust 1.19 would break with > 1.20 and so on. From a distribution maintainer's point of view, this > can be very tedious and annoying. This is not correct for the *stable* compiler, because they provide stability guarantees for it and they do regular "crater runs" (rebuild every crate in the Rust ecosystem, checking if there are any new errors or warnings). I find it quite improbable that you hit this issue in the *stable* compiler (and if you did, it was a bug, and I hope you reported it). The *unstable* compiler (by it's nature) doesn't provide any such guarantees. > Overall, I think the move to memory-safe languages is generally a good > idea. However, I'm still a bit worried with the move to Rust as I think > the language isn't yet as stable as it should be for writing core libraries > in it. My main concern with Rust at the moment is that their ecosystem is very similar to Node. I was trying to write some simple tools in Rust for my own usage, and found that for simple things like email message parsing there are at least 5 libraries which are all incomplete or overly naive. Compare this to Python or Go which has effectively one "common" library that is great and widely used because everyone contributes to the same thing. A common argument is that the Rust ecosystem is young, but I think it's a symptom of their Node-like packaging design. There are some examples of a "one good library", such as nix or tokio, but those are the minority (from what I've seen). I hope this is something that will improve in the near future, because it makes it difficult to get started on a project (or maintain it). -- Aleksa Sarai Senior Software Engineer (Containers) SUSE Linux GmbH <https://www.cyphar.com/> |
In reply to this post by Richard Brown
>
> I would also like to add that snapshot 0117 introduced the new btrfs > default subvolume layout > > Any fresh installation of Tumbleweed using the default btrfs root > filesystem will no longer have multiple subvolumes under /var (eg > /var/lib/mysql, /var/cache, etc) and instead have a single unified > /var subvolume. > > This simplifies snapshots and rollbacks, will prevent accidental > dataloss on rollback for any user data held in /var, and improve > performance of any database or VM images that are held in /var as all > of /var also now has Copy-on-Write disabled by default. > It's also particularly useful for openSUSE Kubic which was struggling > with the consequences of much of /var being read-only as it was > considered part of Kubic's read-only root filesystem. > > > We will not be automatically moving user data from the old structure > to the new one, but I'm open to any suggestions on how to script it if > anyone has any bright ideas. Richard, is there a documented manual way (wiki, github, ml), for those who will not do a reinstall, but would like to move to the new layout ? I'm a bit surprised about removing data checksum on /var (nocow implying this) If you have a bit spare time to point me to some material explaining the decision, I would be really interested. Thanks. -- 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] |
On Sun, Jan 21, Bruno Friedmann wrote:
> > We will not be automatically moving user data from the old structure > > to the new one, but I'm open to any suggestions on how to script it if > > anyone has any bright ideas. > > Richard, is there a documented manual way (wiki, github, ml), for those who > will not do a reinstall, but would like to move to the new layout ? Richard ask for suggestions how this can be done, so no, there is none. > I'm a bit surprised about removing data checksum on /var (nocow implying this) > If you have a bit spare time to point me to some material explaining the > decision, I would be really interested. Please think about what are the advantages of CoW, what the disadvantages and which data is stored below /var. And look how many subvolumes we had before with NoCoW below /var. Then it should be pretty obious, that performance is more important here than the very limited benefit of CRC32. 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] |
On dimanche, 21 janvier 2018 11.46:00 h CET Thorsten Kukuk wrote:
> On Sun, Jan 21, Bruno Friedmann wrote: > > > We will not be automatically moving user data from the old structure > > > to the new one, but I'm open to any suggestions on how to script it if > > > anyone has any bright ideas. > > > > Richard, is there a documented manual way (wiki, github, ml), for those > > who > > will not do a reinstall, but would like to move to the new layout ? > > Richard ask for suggestions how this can be done, so no, there is none. > > > I'm a bit surprised about removing data checksum on /var (nocow implying > > this) If you have a bit spare time to point me to some material > > explaining the decision, I would be really interested. > > Please think about what are the advantages of CoW, what the disadvantages > and which data is stored below /var. And look how many subvolumes we had > before with NoCoW below /var. Then it should be pretty obious, that > performance is more important here than the very limited benefit of CRC32. > > Thorsten Hi Thorsten, while I'm very new in using btrfs, I'm now a puzzled. If I have nocow on /var it means that for example named will be no more protected from data corruption, from my understanding pov. Or I missed one important information ? -- 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] |
In reply to this post by Marco Calistri-3
субота, 20 січня 2018 р. 15:06:47 EET Marco Calistri написано:
> Il 20/01/2018 10:51, Patrick Shanahan ha scritto: > > when will SuSEfirewall2 be migrated to the new firewalld? > > > > tks, > > ...And what happens to users which are relying on Susefirewall2 with > custom rules and settings? > > The firewalld migration is/will be mandatory/silent or could be decided > by the user? > > Thanks and regards, firewalld (another, Python, front-end for iptables). But making GUI for YaST, something like yast-firewalld, looks fine. -- Kind regards, Mykola Krachkovsky -- Найкращі побажання, Микола Крачковський |
* Mykola Krachkovsky <[hidden email]> [01-21-18 07:44]:
> субота, 20 січня 2018 р. 15:06:47 EET Marco Calistri написано: > > Il 20/01/2018 10:51, Patrick Shanahan ha scritto: > > > when will SuSEfirewall2 be migrated to the new firewalld? > > > > > > tks, > > > > ...And what happens to users which are relying on Susefirewall2 with > > custom rules and settings? > > > > The firewalld migration is/will be mandatory/silent or could be decided > > by the user? > > > > Thanks and regards, > > IMHO, there is no sense to port SuSEfirewall2 (Perl front-end for iptables) to > firewalld (another, Python, front-end for iptables). But making GUI for YaST, > something like yast-firewalld, looks fine. you are saying *yast-firewalld* would apply the same "custom" rules and settings? -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: [hidden email] To contact the owner, e-mail: [hidden email] |
In reply to this post by Bruno Friedmann-2
Hi,
I've moved to the new layout so I've written something on how to do it: https://www.alionet.org/content.php?801-openSUSE-change-son-%AB-partitionnement-%BB-Btrfs/view/2. The explanations are in French but the commands are the same in English ;-) Regards, -- Antoine -- To unsubscribe, e-mail: [hidden email] To contact the owner, e-mail: [hidden email] |
In reply to this post by Patrick Shanahan-2
On Sun, Jan 21, Patrick Shanahan wrote:
> > IMHO, there is no sense to port SuSEfirewall2 (Perl front-end for iptables) to > > firewalld (another, Python, front-end for iptables). But making GUI for YaST, > > something like yast-firewalld, looks fine. > > you are saying *yast-firewalld* would apply the same "custom" rules and > settings? I doubt. And to be honest, with something such security relevant I would never trust automatical conversation of custom rules from one software to a complete different software. 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] |
In reply to this post by Antoine Belvire
On 21 January 2018 at 15:43, Antoine Belvire
<[hidden email]> wrote: > Hi, > > I've moved to the new layout so I've written something on how to do it: > https://www.alionet.org/content.php?801-openSUSE-change-son-%AB-partitionnement-%BB-Btrfs/view/2. > > The explanations are in French but the commands are the same in English ;-) This guide is wrong, dangerous, and should not be followed _I strongly recommend against anyone using this guide_ To summarise it's key flaws #1 The guide does not make clear that the new structure should NOT BE USED on Leap 42.3 or earlier distributions. Anyone using a flat /var subvolume on Leap 42.3 or earlier WILL break their system when rolling back because rpm still locates it's database in /var/lib/rpmdb in that version, and hundreds of packages store their fillup-templates in /var/adm still. #2 The guide assumes @ is the correct subvoulme to add the new /var. This is incorrect for many many users. @ does not exist on any installations that are upgraded from old release versions of openSUSE (including installations of Tumbleweed circa 2015 or earlier - it was only introduced around the period of Leap 42.1 IIRC) 3. Even if you correct the guide to address #1 and #2 the guide does nothing to address the fact that every single snapshot will be invalidated, as your old snapshots will still include contents in /var but your root filesystem will now have /var as a subvolume. I admit I am not sure of the consequences of trying to rollback to an old subvolume in this case, but I imagine they will not be pretty. Has anyone tested this? I haven't because the lack of a clear solutions to #1 and #2 put the need for this at the bottom of my list. Please, either correct the document with clear answers to the above issues or remove the guide as soon as possible. Anyone following your guide is at risk of breaking their system, whereas anyone leaving their structure alone, like I intended, will have no problems for the foreseeable future. Regards, Richard Brown Linux Distribution Engineer SUSE Linux GmbH -- To unsubscribe, e-mail: [hidden email] To contact the owner, e-mail: [hidden email] |
In reply to this post by Aleksa Sarai
On 01/21/2018 02:18 AM, Aleksa Sarai wrote:
> On 2018-01-20, John Paul Adrian Glaubitz <[hidden email]> wrote: >> This is actually a huge change as librsvg is a core library with a large >> number of reverse dependencies now partially written in a programming >> language with limited architecture support. > > Yes, I agree this is a problem -- maybe we should keep around an old > version of librsvg purely for "tier 2" architecture support? Aren't arm64, ppc64el and s390x tier 1 architectures in SLE? >> Finally, one problem with Rust that I ran into when working on the >> Rust compiler code itself is the high volatility of the language and the >> code. Things that used to build fine with Rust 1.19 would break with >> 1.20 and so on. From a distribution maintainer's point of view, this >> can be very tedious and annoying. > > This is not correct for the *stable* compiler, because they provide > stability guarantees for it and they do regular "crater runs" (rebuild > every crate in the Rust ecosystem, checking if there are any new errors > or warnings). I find it quite improbable that you hit this issue in the > *stable* compiler (and if you did, it was a bug, and I hope you reported > it). The *unstable* compiler (by it's nature) doesn't provide any such > guarantees. One example for this is the fact that you need exactly version N-1 to build version N of the Rust compiler. Using a slightly older version or even version N does not work. Tried that several times. This was extremely annoying when I was working on the sparc64 code in the Rust compiler. Adrian -- To unsubscribe, e-mail: [hidden email] To contact the owner, e-mail: [hidden email] |
In reply to this post by Richard Brown
21.01.2018 21:21, Richard Brown пишет:
> On 21 January 2018 at 15:43, Antoine Belvire > <[hidden email]> wrote: >> Hi, >> >> I've moved to the new layout so I've written something on how to do it: >> https://www.alionet.org/content.php?801-openSUSE-change-son-%AB-partitionnement-%BB-Btrfs/view/2. >> >> The explanations are in French but the commands are the same in English ;-) > > This guide is wrong, dangerous, and should not be followed > > _I strongly recommend against anyone using this guide_ > > To summarise it's key flaws > > #1 The guide does not make clear that the new structure should NOT BE > USED on Leap 42.3 or earlier distributions. > Anyone using a flat /var subvolume on Leap 42.3 or earlier WILL break > their system when rolling back because rpm still locates it's database > in /var/lib/rpmdb in that version, and hundreds of packages store > their fillup-templates in /var/adm still. > You cannot forbid users to chose arbitrary filesystem layout during installation. If this is so dangerous, snapper should refuse to perform rollback (or even create snapshots actually). If snapper allows it, how can you blame users? -- To unsubscribe, e-mail: [hidden email] To contact the owner, e-mail: [hidden email] |
In reply to this post by Richard Brown
Hi,
Le 21/01/2018 à 19:21, Richard Brown a écrit : > On 21 January 2018 at 15:43, Antoine Belvire > <[hidden email]> wrote: >> Hi, >> >> I've moved to the new layout so I've written something on how to do it: >> https://www.alionet.org/content.php?801-openSUSE-change-son-%AB-partitionnement-%BB-Btrfs/view/2. >> >> The explanations are in French but the commands are the same in English ;-) > > This guide is wrong, dangerous, and should not be followed Nice! > > _I strongly recommend against anyone using this guide_ > > To summarise it's key flaws > > #1 The guide does not make clear that the new structure should NOT BE > USED on Leap 42.3 or earlier distributions. > Anyone using a flat /var subvolume on Leap 42.3 or earlier WILL break > their system when rolling back because rpm still locates it's database > in /var/lib/rpmdb in that version, and hundreds of packages store > their fillup-templates in /var/adm still. The explanations in French that accompany the commands (especially on page 1: https://www.alionet.org/content.php?801-openSUSE-change-son-%AB-partitionnement-%BB-Btrfs) makes clear that this is for Tumbleweed and only that Tumbleweed has performed the necessary changes to be able to do that. And that there are already pretty clear warnings that say that no one who does not understand the commands should perform them. So this particular point is invalid to me. > > #2 The guide assumes @ is the correct subvoulme to add the new /var. > This is incorrect for many many users. > @ does not exist on any installations that are upgraded from old > release versions of openSUSE (including installations of Tumbleweed > circa 2015 or earlier - it was only introduced around the period of > Leap 42.1 IIRC) True. I could precise this. I installed Tumbleweed when there was no @. I added it a few months ago. Not very complicated too. > 3. Even if you correct the guide to address #1 and #2 the guide does > nothing to address the fact that every single snapshot will be > invalidated, as your old snapshots will still include contents in /var > but your root filesystem will now have /var as a subvolume. > I admit I am not sure of the consequences of trying to rollback to an > old subvolume in this case, but I imagine they will not be pretty. > Has anyone tested this? I haven't because the lack of a clear > solutions to #1 and #2 put the need for this at the bottom of my list. True, I didn't write information about this. I guess that if old snapshots are restored then the content in old directory /var would be restored, the new @/var subvolume would just exist without being mounted. I think the main problem would be the old subvolumes below var and their contents which are lost. One could try to keep these subvolumes instead of deleting them and just remove them from fstab, I don't know if it's enough to keep rollback possible. > Please, either correct the document with clear answers to the above > issues or remove the guide as soon as possible. > Anyone following your guide is at risk of breaking their system, > whereas anyone leaving their structure alone, like I intended, will > have no problems for the foreseeable future. I won't remove this "guide", thank you. Anyway you've made clear that you don't support it :-P I may add/improve warnings for #2 and #3 though. My aim is not to deliver a universal guide - I would have started by writing in English. It just works for me. I hope it can help others. Cheers, -- Antoine -- To unsubscribe, e-mail: [hidden email] To contact the owner, e-mail: [hidden email] |
In reply to this post by Andrei Borzenkov
Op zondag 21 januari 2018 20:02:26 CET schreef Andrei Borzenkov:
> 21.01.2018 21:21, Richard Brown пишет: > > On 21 January 2018 at 15:43, Antoine Belvire > > > > <[hidden email]> wrote: > >> Hi, > >> > >> I've moved to the new layout so I've written something on how to do it: > >> https://www.alionet.org/content.php?801-openSUSE-change-son-%AB-partition > >> nement-%BB-Btrfs/view/2. > >> > >> The explanations are in French but the commands are the same in English > >> ;-) > > > > This guide is wrong, dangerous, and should not be followed > > > > _I strongly recommend against anyone using this guide_ > > > > To summarise it's key flaws > > > > #1 The guide does not make clear that the new structure should NOT BE > > USED on Leap 42.3 or earlier distributions. > > Anyone using a flat /var subvolume on Leap 42.3 or earlier WILL break > > their system when rolling back because rpm still locates it's database > > in /var/lib/rpmdb in that version, and hundreds of packages store > > their fillup-templates in /var/adm still. > > You cannot forbid users to chose arbitrary filesystem layout during > installation. If this is so dangerous, snapper should refuse to perform > rollback (or even create snapshots actually). If snapper allows it, how > can you blame users? I don't see Richard forbidding things. Strongly recommending against it, yes. No software can completely armour itself against user misconfiguration. -- Gertjan Lettink, a.k.a. Knurpht openSUSE Board Member openSUSE Forums Team -- To unsubscribe, e-mail: [hidden email] To contact the owner, e-mail: [hidden email] |
In reply to this post by Antoine Belvire
Le 21/01/2018 à 20:38, Antoine Belvire a écrit :
> I may add/improve warnings for #2 and #3 though. I've added some warnings just now. Good night, -- Antoine -- To unsubscribe, e-mail: [hidden email] To contact the owner, e-mail: [hidden email] |
In reply to this post by Andrei Borzenkov
On 21 January 2018 at 20:02, Andrei Borzenkov <[hidden email]> wrote:
> > You cannot forbid users to chose arbitrary filesystem layout during > installation. If this is so dangerous, snapper should refuse to perform > rollback (or even create snapshots actually). If snapper allows it, how > can you blame users? Users cannot customise a separate /var filesystem in our basic tools provided. Neither the standard workflow nor the easy "Guided Setup" workflow allows it. We allow users to do lots of stupid stuff in the Expert partitioner, that's why it's the _Expert_ partitioner, and provides that question where the user must state that they know what they are doing If a user chooses a separate /var filesystem on a version of openSUSE that stores it's rpm database in /var (ie. Leap 42.3 and earlier), then either - a) the user is doing something stupid and they shouldn't have said they know what they are doing when opening the Expert partioner - b) the user knows what they are doing and have a custom solution to snapshot & restore /var in parallel to / Either way, it's not snapper's fault that the user has chosen to go above and beyond the default configuration we've provided. When we warn users with stuff like the Expert Partitioner warning, users should absolutely take responsibility for the decisions they make in such tooling. -- To unsubscribe, e-mail: [hidden email] To contact the owner, e-mail: [hidden email] |
Free forum by Nabble | Edit this page |