On 02/10/2018 04:06 PM, Bruce Ferrell wrote:

On 02/10/2018 03:54 PM, David C. Rankin wrote:

...

On 02/10/2018 03:09 PM, Richard Brown wrote:

...

I think it might be valuable to a museum, but I honestly cannot understand how anyone could possibly want to run a system that is so encumbered with ancient history.

What benefit do you think you get from such an approach to computing?

How do you think someone running an IBM PC 5150 in 1999 would have been seen by the people developing Linux 2.2 and SUSE 6.2? Ok,

   We get. You weren't the kind of a kid that would sit around playing with a Blue Box...

More the kind to hide and throw rocks if you don't agree.  I'm doing a final test to see if the server has blocked all my posts or just some of the lists

OK... It seems just SOME of the lists.  That's just tacky. If my posts have been silently disallowed, just unsubscribe me. David,  Thanks for putting up with my experiment. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday, 2018-02-11 at 17:30 +0100, jdd@dodin.org wrote:

Le 11/02/2018 à 17:25, Dave Plater a écrit :

...

Carlos has been using SuSE and then openSUSE since SuSE 6.2 (My first installation was 6.3 or 4 I can't remember) and he has updated his system since then. He is now on Leap:42.3.

miracle the hardware is still here :-)

No, the hardware was also upgraded. And the arch, 32 -> 64 bits :-) I build a new box, install disks, install a new system to test it, and from that new seed system, create empty partition structure (/mnt, /mnt/usr, /mnt/home), then use nfs or rsync to transfer files from old machine to new machine, chroot, install grub for that partition, then boot it. Change some settings, like different IP, different name. Once verified that it runs, then boot installation media in 64 bit mode and upgrades the transferred system from 32 to 64 bit. That was with oS 11.2, 2010-09-21. I said that I had upgraded both software and hardware at the proper points. ;-) - -- Cheers, Carlos E. R. (from openSUSE 42.3 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlqAs/sACgkQtTMYHG2NR9W/AACdFAcjYXAc1oIx4wCyKaDfbxA8 mKgAn2VymfsOr4DLV4TxMrhxRXHkw4BG =s62m -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday, 2018-02-11 at 23:44 +0100, jdd@dodin.org wrote:

Le 11/02/2018 à 22:22, Carlos E. R. a écrit :

...

upgrades the transferred system from 32 to 64 bit. That was with oS 11.2, 2010-09-21.

I heard it was not allowed :-(

No, not supported. It could work, or it could fail. I heard of people having success with it (I asked), so I went ahead.

anyway, I try to exclude this sort of procedure: first like this one lose the news defaults, also I like to test a lot of applications I don't use anymore after some time and forget, so my install because bigger

so A new install from scratch is often a good thing for me

I prefer not to have to configure again things, or having to remember what to install. My current system installs about 20 GB of packages - I'm unsure if that's the compressed or the expanded size. - -- Cheers, Carlos E. R. (from openSUSE 42.3 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlqAzUYACgkQtTMYHG2NR9X7TwCeNk68f55qkRebtPsmJBrLVGbC GuEAniifS+kXvVrfmkFdCDb5E8wnR/sY =5cyg -----END PGP SIGNATURE-----

On 2018-02-14 06:32, Basil Chupin wrote:

On 12/02/18 10:09, Carlos E. R. wrote:

...

On Sunday, 2018-02-11 at 23:44 +0100, jdd@dodin.org wrote:

...

Le 11/02/2018 à 22:22, Carlos E. R. a écrit :

...

...

  upgrades the transferred system from 32 to 64 bit. That was with oS 11.2,   2010-09-21.

...

I heard it was not allowed :-(

No, not supported. It could work, or it could fail. I heard of people having success with it (I asked), so I went ahead.

...

anyway, I try to exclude this sort of procedure: first like this one lose the news defaults, also I like to test a lot of applications I don't use anymore after some time and forget, so my install because bigger

...

so A new install from scratch is often a good thing for me

I prefer not to have to configure again things, or having to remember what to install.

I have mentioned this before and now repeat...:-):

I always have two (2) HDs in my system with one with the system installed [#] and the second HD having a partition which holds data/config files; I then symlink certain files/directories to this partition from the system on the first HD. Because I always do a clean install, so as to avoid accumulating "baggage" from the older OS, I only have to pay attention to creating the necessary symlinks -- which is a 'snap' when using mc (midnight commander), just 4 clicks of the mouse per symlink.

Does not apply to system wide configs.

...

My current system installs about 20 GB of packages - I'm unsure if that's the compressed or the expanded size.

Good grief! 20GB of *packages*? :-)  Here, the OS part of Leap 42.3 (on HD0) takes up only 3.7GB installed and the data part, sitting on HD1, is 4.5GB big (OK, this goes up when I download a copy of Leap or Tumbleweed or whatever) -- a total of 8.2GB.  :-)

cer@Telcontar:~> df -h Filesystem Size Used Avail Use% Mounted on /dev/sde5 148G 47G 94G 34% / /dev/sdb8 50G 1,7G 49G 4% /opt /dev/sdc14 39G 3,4G 34G 10% /usr/local /dev/sdc13 64G 16G 49G 25% /data/Lareiserfs (holds /usr/src and /var/spool/news and some game terrain data) Not counting /home or data

[#] I normally create 4 or 5 30GB-sized partitions to be able to install versions of Linux distros if I want to experiment. At the moment I have Leap 42.3, Leap 15.0 and Tumbleweed installed. Creating 30GB partitions is an overkill I know, but it 'sounds' better than 20 or 40... :-)

See above >:-) But my laptop test partition is 9 gigs, including home. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)

On 02/13/2018 11:32 PM, Basil Chupin wrote:

I always have two (2) HDs in my system with one with the system installed [#] and the second HD having a partition which holds data/config files; I then symlink certain files/directories to this partition from the system on the first HD. Because I always do a clean install, so as to avoid accumulating "baggage" from the older OS, I only have to pay attention to creating the necessary symlinks -- which is a 'snap' when using mc (midnight commander), just 4 clicks of the mouse per symlink.

<snip>

[#] I normally create 4 or 5 30GB-sized partitions to be able to install versions of Linux distros if I want to experiment. At the moment I have Leap 42.3, Leap 15.0 and Tumbleweed installed. Creating 30GB partitions is an overkill I know, but it 'sounds' better than 20 or 40... :-)

BC

Hey, Basil - up here HDDs are cheap, US$30 for 1TB, US$50 for 2TB, etc. I would assume that even down under they are not terribly expensive. Even a boxed WD Blue 5400rpm 2TB HDD is US$63. Current prices as of today from Microcenter.com . Other outfits like Frys have similar pricing, which is to say that worrying about HDD space is unnecessary. Splurge a bit, feel the freedom of all that elbow room. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 02/16/2018 12:55 AM, Basil Chupin wrote:

(<Sigh>. Oh, you youngsters are always jumping to occlusions.) :-)

All my HDs are 1TB or 2TB big, and most sit in cradles so I can swap in/out the HDs at whim.

But just because I have TBs coming out of my ears doesn't mean I have to use and format 1TB just for Leap 15.0 or for Tumbleweed :-).

What's that saying..."Waste not, want not"? :-)

BC

If, by "youngsters", you mean 70-ish, then you are correct. Waste not, want not - what a quaint concept. I thought that went out with CASE tools. "The system will expand to fill the memory available" has been the mantra since the beginning, which is why it is so hard to tell if said expansion is by design or memory leak. My /home partition is huge and has all my VirtualBox drives on it, my /home2 is also rather large and contains all the movies, spare drives are for backup. My how we have progressed from a box of backup floppys to a couple of mighty HDDs. At least with those I can start the backup and go to bed instead of hovering over the system until it's done. Enjoy those warm summer breezes down there. It only got up to 28 here yesterday. Celcius, that is. (Texas, of course) Fred -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 17/02/18 00:21, Stevens wrote:

On 02/16/2018 12:55 AM, Basil Chupin wrote:

...

(<Sigh>. Oh, you youngsters are always jumping to occlusions.) :-)

All my HDs are 1TB or 2TB big, and most sit in cradles so I can swap in/out the HDs at whim.

But just because I have TBs coming out of my ears doesn't mean I have to use and format 1TB just for Leap 15.0 or for Tumbleweed :-).

What's that saying..."Waste not, want not"? :-)

BC

If, by "youngsters", you mean 70-ish, then you are correct. Waste not, want not - what a quaint concept. I thought that went out with CASE tools. "The system will expand to fill the memory available" has been the mantra since the beginning,

A weakened version of the original Parkinson's Law: "Work expands so as to fill the time available for its completion" :-).

which is why it is so hard to tell if said expansion is by design or memory leak.

My /home partition is huge and has all my VirtualBox drives on it, my /home2 is also rather large and contains all the movies, spare drives are for backup. My how we have progressed from a box of backup floppys to a couple of mighty HDDs. At least with those I can start the backup and go to bed instead of hovering over the system until it's done.

Why don't you put all that...aahhh...extra stuff on another HD or partition(s) and have symlinks from inside /home to that extra stuff on the other HD/partition(s) thus leaving /home "clean"? If any of my OSs go down all my data is sitting safely elsewhere, and all I need do is to do regular backups of "the other place" and not my /home(s). In fact, when I do a 'clean' install of the latest version of, say, Leap I simply reformat "/" and install and then create the symlinks. But, as one sage who frequents this list is wont of saying, "whatever floats yer boat" :-)

Enjoy those warm summer breezes down there. It only got up to 28 here yesterday. Celcius, that is. (Texas, of course) Texas, eh? 28C, eh? Must be all that hot air coming down from D.C., right? :-D Currently sitting on 31C here, and the air conditioning is on...luvly :-)

BTW, your opening sentence (above) caused me to wonder about how many people who are, say, between teens and 30 years of age who actually use openSUSE. BC -- Always be nice to people on your way up -- you'll see the same people on your way down. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 11 February 2018 at 17:25, Dave Plater wrote:

Can I please take time to translate english, which I am so I understand it, into english understandable by Richard. Carlos has been using SuSE and then openSUSE since SuSE 6.2 (My first installation was 6.3 or 4 I can't remember) and he has updated his system since then. He is now on Leap:42.3. There is no mention that he has recently run SuSE 6.2 or attempted to update 42.3 from it.

Carlos said, and I quote:

...

Ok, but my system has been upgraded from SuSE 6.2 upwards (ie, it is much older than 13.x), so it will not work. And I do not use btrfs, either.

"my system". Carlos' choice of language indicates a singular system that was upgraded from SuSE 6.2 upwards. The reference to "it" (again, singular, related to "my system") and "older than 13.x" confirms that Carlos is talking about a single system, which he has upgraded from 6.2 Whether he upgraded from 6.2 directly to Leap or incrementally (eg. 6.2 > 6.3 > .... 13.2 > 42.1 > 42.2 > 42.3) does not diminish my concern, undermine my points, nor dilute my opinion that I think it's a downright stupid thing to do, for reasons I will explain in my reply to Anton below. On 11 February 2018 at 18:10, Anton Aylward wrote:

So what was Richard's problem? He's normally erudite and can't be that stupid: no, I think he was trolling.

Thank you for the compliment, and I assure you I was not trolling. Upgrade is one of the hardest tasks to do right for a system. Each system has hundreds or thousands of packages on them. For each one, the packager of each new version needs to make sure that they correct package that new version to ensure that it smoothly upgrades to that new version. "smoothly" in this case means not only "the new version works", but also "cleaned up after the old version". Individually, looking at the problem on package at a time, that is a complex enough problem. But the reality is that each packager also needs to factor in every dependency of every package they rely on, and ensure those too are upgraded appropriately and smoothly relative to the each and every other package. Basically, getting it right 100% of the time is impossible. Through heavy testing and a lot of luck we just about get it 'good enough' for every release. And this is now, in 2018, where we have zypper and rpm carrying features like post_installation scripts. Back in the olden days the hacks and tweaks and tunings needed to get a smooth upgrade weren't even possible, so even if we did it as 100% effectively as we possibly could back then, we were BOUND to be leaving unhandled nonsense on your system. And even with those tools, we sometimes have to make hard decisions. This is a topic which I can speak of with intimate authority - I've done it repeatedly as a packager, most lately (and scarily), with my recent orchestration of the rpmdb move. In order to do it smoothly, i had to make a conscious decision just how far back to support the upgrade process for. I wilfully chose not to support installations 10.x and earlier. It might work, but I actively worked around previously existing code that otherwise would have hindered the upgrade process for modern versions. I would expect it to break, and I did not bother testing it, because 10.x is no longer supported in any way manner or form. But it's entirely possible that a system originally a 10.x version would still carry around elements, database configurations, file locations, and such, from those days. I cannot promise that a system upgraded from 10.x will have always done so cleanly. It was a conscious decision of me to allow the possibility of breakage in such a case, in order to be able to do the upgrade easily on systems that are from supported versions. Reasons like this is why SUSE have very strict upgrade support matrices. SUSE expects their enterprise customers to do fresh installations once in a while, like when buying new hardware. I do like the fact that openSUSE does 'best reasonable efforts' on a broader scale, but I do not think supporting a "system has been upgraded from SuSE 6.2 upwards" is reasonable. So, if you consider the human factor, I think it is highly inadvisable to indefinitely upgrade a system from too many years ago. Our maintainers are not thinking in such terms, and even if we were, we're human, and the chances of us screwing something up somewhere in the chain get larger and larger. If you think we're 99.9% percent perfect (and we're not), then consider a small installation of 400 packages (and most people have many more). Every second upgrade you can pretty much guarantee we messed up at least one package. It might not be one you notice, but it's there. And gather enough of them, and you'll start noticing weird behaviour. Using Carlos' example, he's upgraded around 25 times to get his system where it is. I think a rough guideline would be to do a fresh installation at least once every 4-5 versions (for versions 13.2 and earlier - where this risk was A LOT higher with every version) or every 2-3 major versions (in the new Leap development model - where this risk is less thanks to the benefit of working with SUSE on the base system) On one side, sure, like he says, I AM proud that his system works still. But on the other side, I believe him to be deluded if he believes his system is working WELL. And I think can prove it. Obvious symptoms of the kind of problems I would expect from the sort of packaging-cruft you're going to collect over time include issues like dependency warnings and package conflicts related to packages removed from our distributions a long time ago, but for some reason still hanging around on a system upgraded in this manner. The reason such old packages are liable to hang around is because of the very sort of mistakes that are bound to happen during upgrades. Especially if those upgrades also include devel projects, where we don't even consider upgradability, ever. Such packages often end up orphaned, living on the system pretending they belong to a @System repo. You know, something like this issue.. https://lists.opensuse.org/opensuse/2018-02/msg00302.html So this thread isn't just a baseless rant, or a troll, but a cry of frustration..it hurts me seeing people holding a mindset that leads to them hurting themselves. I don't suffer fools gladly, and yet I know this list contains others that share Carlos' mindset. Hence trying to illuminate the topic and asking the questions that I did. If I cant persuade the people holding this mindset that they're wrong, then I might at least learn something that will give me a method of better demonstrating just how wrong it is. You could see this situation as analogous to gambling, with every version being a roll of the dice. I could just be happy that the gamblers are happy to be playing the game, and turn a blind eye to the debts racking up on their account. But I'd rather openSUSE users don't follow bad practices that create technical debt for themselves. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday, 2018-02-11 at 20:57 +0100, Richard Brown wrote:

On 11 February 2018 at 17:25, Dave Plater wrote:

...

Can I please take time to translate english, which I am so I understand it, into english understandable by Richard. Carlos has been using SuSE and then openSUSE since SuSE 6.2 (My first installation was 6.3 or 4 I can't remember) and he has updated his system since then. He is now on Leap:42.3. There is no mention that he has recently run SuSE 6.2 or attempted to update 42.3 from it.

Carlos said, and I quote:

...

...

Ok, but my system has been upgraded from SuSE 6.2 upwards (ie, it is much older than 13.x), so it will not work. And I do not use btrfs, either.

"my system". Carlos' choice of language indicates a singular system that was upgraded from SuSE 6.2 upwards. The reference to "it" (again, singular, related to "my system") and "older than 13.x" confirms that Carlos is talking about a single system, which he has upgraded from 6.2

"my system" doesn't have to be the same hardware... Same as "my car" is not the same car. It denotes the machine and software that I use.

Whether he upgraded from 6.2 directly to Leap or incrementally (eg. 6.2 > 6.3 > .... 13.2 > 42.1 > 42.2 > 42.3) does not diminish my concern, undermine my points, nor dilute my opinion that I think it's a downright stupid thing to do, for reasons I will explain in my reply to Anton below.

On 11 February 2018 at 18:10, Anton Aylward wrote:

...

So what was Richard's problem? He's normally erudite and can't be that stupid: no, I think he was trolling.

Thank you for the compliment, and I assure you I was not trolling.

Upgrade is one of the hardest tasks to do right for a system.

Then you should be very proud that SuSE/SUSE/openSUSE has done it extremly well.

Each system has hundreds or thousands of packages on them.

For each one, the packager of each new version needs to make sure that they correct package that new version to ensure that it smoothly upgrades to that new version.

"smoothly" in this case means not only "the new version works", but also "cleaned up after the old version".

Individually, looking at the problem on package at a time, that is a complex enough problem. But the reality is that each packager also needs to factor in every dependency of every package they rely on, and ensure those too are upgraded appropriately and smoothly relative to the each and every other package.

Basically, getting it right 100% of the time is impossible. Through heavy testing and a lot of luck we just about get it 'good enough' for every release.

And this is now, in 2018, where we have zypper and rpm carrying features like post_installation scripts. Back in the olden days the hacks and tweaks and tunings needed to get a smooth upgrade weren't even possible, so even if we did it as 100% effectively as we possibly could back then, we were BOUND to be leaving unhandled nonsense on your system.

Back in the SuSE days, the quality control at SuSE was astonishing. It was why many people used SuSE and not others. In words of the late DenverD: openSUSE®, the "German Engineered Automobiles" of operating systems! If there are files there that should not be there, well, it is somebody fault, but not mine. Say I upgrade from one version to the next, and those files are left there, then it is the fault of the people that created that upgrade then and there. You are saying those people did a bad job. I say they did a wonderful job. So I upgrade to next version a year later, and those files that were left over remain left over. SO WHAT? No package is using them, and I make sure that there are no old packages remaining. No issues. And if there are issues, *we* solve them. We have a great communitty, and if someone can't solve an issue, some other person gives an idea and we solve it.

And even with those tools, we sometimes have to make hard decisions. This is a topic which I can speak of with intimate authority - I've done it repeatedly as a packager, most lately (and scarily), with my recent orchestration of the rpmdb move.

In order to do it smoothly, i had to make a conscious decision just how far back to support the upgrade process for. I wilfully chose not to support installations 10.x and earlier. It might work, but I actively worked around previously existing code that otherwise would have hindered the upgrade process for modern versions. I would expect it to break, and I did not bother testing it, because 10.x is no longer supported in any way manner or form. But it's entirely possible that a system originally a 10.x version would still carry around elements, database configurations, file locations, and such, from those days. I cannot promise that a system upgraded from 10.x will have always done so cleanly. It was a conscious decision of me to allow the possibility of breakage in such a case, in order to be able to do the upgrade easily on systems that are from supported versions.

But it is not a system upgraded from 10.x to 42.3. It is a system that was upgraded from 10.1 to 10.2 (for example) and the cruft was left there at that point, and it is the fault of the people that created 10.2. The faults are, if they exist, distributed over all the years and all the versions and their creators. But the fact is that there is no such cruft harming the system, so nobody to blame. The thing is, upgrade from 10.1 to 10.2 is legal. Upgrade from 10.2 to 10.3 is legal. Upgrade from 10.3 to 11.1 is legal. Upgrade from 11.1 to 11.2 is legal. Upgrade from 11.2 to 11.3 is legal. Etc. Are you going to place a limit? A new limit?

Reasons like this is why SUSE have very strict upgrade support matrices. SUSE expects their enterprise customers to do fresh installations once in a while, like when buying new hardware. I do like the fact that openSUSE does 'best reasonable efforts' on a broader scale, but I do not think supporting a "system has been upgraded from SuSE 6.2 upwards" is reasonable.

So, if you consider the human factor, I think it is highly inadvisable to indefinitely upgrade a system from too many years ago. Our maintainers are not thinking in such terms, and even if we were, we're human, and the chances of us screwing something up somewhere in the chain get larger and larger. If you think we're 99.9% percent perfect (and we're not), then consider a small installation of 400 packages (and most people have many more). Every second upgrade you can pretty much guarantee we messed up at least one package. It might not be one you notice, but it's there. And gather enough of them, and you'll start noticing weird behaviour.

Using Carlos' example, he's upgraded around 25 times to get his system where it is. I think a rough guideline would be to do a fresh installation at least once every 4-5 versions (for versions 13.2 and earlier - where this risk was A LOT higher with every version) or every 2-3 major versions (in the new Leap development model - where this risk is less thanks to the benefit of working with SUSE on the base system)

And I say that there is no such arbitrary limit. I have more confidence in the good work of openSUSE people than you :-)

On one side, sure, like he says, I AM proud that his system works still. But on the other side, I believe him to be deluded if he believes his system is working WELL.

And I think can prove it.

Try.

Obvious symptoms of the kind of problems I would expect from the sort of packaging-cruft you're going to collect over time include issues like dependency warnings and package conflicts related to packages removed from our distributions a long time ago, but for some reason still hanging around on a system upgraded in this manner.

The reason such old packages are liable to hang around is because of the very sort of mistakes that are bound to happen during upgrades. Especially if those upgrades also include devel projects, where we don't even consider upgradability, ever.

Such packages often end up orphaned, living on the system pretending they belong to a @System repo.

There are no orphaned packages that belong to previous openSUSE releases in my system and I can prove it. The procedure is documented.

You know, something like this issue..

https://lists.opensuse.org/opensuse/2018-02/msg00302.html

So this thread isn't just a baseless rant, or a troll, but a cry of frustration..it hurts me seeing people holding a mindset that leads to them hurting themselves. I don't suffer fools gladly, and yet I know this list contains others that share Carlos' mindset.

But you are mistaken: libgd3 was installed recently (2018-02-04). It was not installed a month ago, with 42.2. I know, I have logs. I just checked the old logs and I know for certain it was not intalled. It was installed a week ago, in fact, for the first time: # 2018-02-04 22:24:48 libgd3-2.2.5-131.1.x86_64.rpm installed ok # Additional rpm output: # /sbin/ldconfig: /usr/lib/libGLcore.so.1 is not a symbolic link # # /sbin/ldconfig: /usr/lib64/libscintilla.so.3 is not a symbolic link # # 2018-02-04 22:24:48|install|libgd3|2.2.5-131.1|x86_64|4658:ruby|OBS_graphics|d1327b33c7db06d347df8570c1d8d9c62a2c1c27e2f654fdc0a63234d2c74deb| and updated yesterday, when I got the conflict: 2018-02-10 19:53:34|install|handbrake-gtk-lang|1.0.7-3.21|noarch|root@Telcontar|EXT_Packman|2048b7a69e593af2a9b1e002e52671bf69937216d026d4750122cb48631d32a5| # 2018-02-10 19:53:35 libgd3-2.2.5-134.1.x86_64.rpm installed ok # Additional rpm output: # /sbin/ldconfig: /usr/lib/libGLcore.so.1 is not a symbolic link # # /sbin/ldconfig: /usr/lib64/libscintilla.so.3 is not a symbolic link # # /sbin/ldconfig: /usr/lib/libGLcore.so.1 is not a symbolic link # # /sbin/ldconfig: /usr/lib64/libscintilla.so.3 is not a symbolic link # # 2018-02-10 19:53:35|install|libgd3|2.2.5-134.1|x86_64|root@Telcontar|OBS_graphics|586ec104d9d3fdcfc8b083a83f0f1d2bf492644379851915ca1043e3d6f3c5ae|2 And this package: gd-2.1.0-24.1.x86_64 (@System) is in fact from 42.3 repos. It was installed, version gd-2.1.0-11.1, on 2016-12-26. First time that it appears in the logs since 2014-02-25. gd-2.1.0-13.1 was installed 2017-01-04 And the Leap 42.3 version was installed last january: # 2018-01-31 16:08:22 gd-2.1.0-18.3.1.x86_64.rpm installed ok and upgraded On Feb-4 to the version that you saw on the mail. Not cruft. @System in this case means some failure of the rpm database to properly log where the package came from, or package lacking that info, but it is indeed from 42.3, listed in my logs: {INSTALLTIME:day} {BUILDTIME:day} {NAME} {VERSION} {RELEASE} {arch} {VENDOR}%25{PACKAGER} == %{DISTRIBUTION} %{DISTTAG}\n" Sun Feb 04 2018 Mon Jan 29 2018 gd 2.1.0-24.1 x86_64 openSUSE http://bugs.opensuse.org == openSUSE Leap 42.3 (none) Zypper knows (se -si), info from Feb 4: S | Name | Type | Version | Arch | Repository - ---+-----------------------------------------------+-------------+--------------------------------------+--------+-------------------------- i+ | gd | package | 2.1.0-24.1 | x86_64 | Main Update Repository So try again. What cruft from previous versions do I have?

Hence trying to illuminate the topic and asking the questions that I did. If I cant persuade the people holding this mindset that they're wrong, then I might at least learn something that will give me a method of better demonstrating just how wrong it is.

You could see this situation as analogous to gambling, with every version being a roll of the dice. I could just be happy that the gamblers are happy to be playing the game, and turn a blind eye to the debts racking up on their account. But I'd rather openSUSE users don't follow bad practices that create technical debt for themselves.

Then go ahead and document it officially: what is the limit to system upgrades of the stable version? Tell that to the community. And to the TW community, because they are doing thousands of upgrades... they should have tons of cruft. - -- Cheers, Carlos E. R. (from openSUSE 42.3 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlqAxmsACgkQtTMYHG2NR9VbdQCeNjemZQhEkDyj7AWZJ0YKiCbo qLUAniRDCSOKDLE+3Na8lCBO6kmTdeQe =n1Yl -----END PGP SIGNATURE-----

Richmond wrote:

Carlos E. R. wrote:

...

openSUSE®, the "German Engineered Automobiles" of operating systems!

Does that mean we should check the emissions again?

It always wise to keep one's emissions in check. -- Per Jessen, Zürich (0.3°C) http://www.cloudsuisse.com/ - your owncloud, hosted in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 11/02/18 21:57, Richard Brown wrote:

"my system". Carlos' choice of language indicates a singular system that was upgraded from SuSE 6.2 upwards.

This is an example of why artificial intelligence will never replace human beings. A human being instinctively knows that "my system" relates to the computing environment that Carlos uses and not to the actual mother board and hard drives he had SuSE 6.2 installed on. Bear in mind that this list consists of both 1st language English speakers and 2nd language English speakers from all over the world and try to use human thinking to understand what is actually implied. Dave P -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 12/02/18 20:25, Ken Schneider - openSUSE wrote:

And keep in mind that in the english language that not all statements can be taken literally.

Keep in mind also that those non-literal statements can change - indeed can mean exactly the opposite - depending on whether you are speaking English, American, Strine, or any one of the gamut of languages that are called "English". Cheers, Wol -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org