|
|
1234
... 6
|
|
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.netPhotos: 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,
>
...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,
--
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/>
|
|
|
>
> 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]
|
|
|
субота, 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.
--
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.netPhotos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]
|
|
|
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]
|
|
|
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]
|
|
|
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]
|
|
|
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]
|
|
|
Hi,
Le 21/01/2018 à 19:21, Richard Brown a écrit :
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]
|
|
|
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]
|
|
|
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]
|
|
|
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]
|
1234
... 6
|
Locked
signature.asc (201 bytes)