Wine is essential for many of us

Hello,

Outside of this debate on flatpak vs apt, could someone point to a reliable method to have a working wine installation on KDE neon after plasma 6 update?
If It needs to use flatpak so be it, but tell me how to make it work.

You need to use flatpak for wine

2 Likes

Now I’m thinking of playing with linuxfromscratch, see if I can have flatpaks/snaps on top of these and see where it would lead me. :laughing:

I skimmed over this thread to see if anyone mentioned this, but the reason this probably happened to you is that to install WINE from Winehq, you need an old version of libpoppler and the newer packages want a new version of libpoppler.
So when I upgraded (through Apt) a few important packages were kept back because of this, so I used aptitude to select the latest version of libpoppler, let Wine uninstall, then when the upgrade completed, I manually installed the old version of libpoppler again, and reinstalled Wine. And that worked.
As an alternative you can use Lutris to install its own versions of Wine, but I’m pretty sure you’ll need to launch any windows applications through Lutris if you do that.
I’m not sure if this will work for anyone else because I’ve usually used Apt since pkcon and Discover haven’t always been the most reliable.

That wasn’t my case. I don’t have any 3rd party repo about wine. During the failed update, I somehow managed to keep wine64 and remove win32:i386 along with some other i386 packages which seemed to be the issue. I’m now using a monster distro I guess. wine64 is still working for my case: I need it to manage my router (mikrotik) through the windows only winbox application. Steam (not a flatpak) also seem to not be affected by this, and I’m wondering at that point if steam still needs and relies any of the i386 packages provided by the OS. In any case I guess steam also needs to be installed as flatpak.

The way I’d answer those:

It doesn’t have to be. But it has always provided a huge feedback for bugs, most definitely. It’s one of the main tools to do QA.

It is again a case of “it doesn’t have to be”. It’s certainly used by developers, and one of the most convenient ways to develop KDE software in containers. If you need packages coming straight from git for container development, it’s the only easy way to do so.

I’m pretty sure it originated for developers, but with the release of User Edition it grew more and more popular among enthusiast users. So nowadays it’s both.

But that’s a leading question. The real question is “who is it for/targetting?”, and the answer is “enthusiasts”, like the FAQ says.

“As such, the ideal KDE neon user is someone excited to use the latest and greatest KDE software who can tolerate some bumps in the road from time to time, not someone with mission-critical reliability needs.”

Dunno if that’s what Nate added recently, but it’s very clear at least.

No. The FAQ also says this.

User Edition is, while Testing, Unstable and Developer aren’t.

1 Like

It’s not radical at all in the server side. Starting with CoreOS, one decade ago. Nowadays, for many datacenter machines, all that required for a “server OS” is being able to run a k8s node.

But Flatpak is more complex than Docker, with explicit dependencies (Runtime). It almost feels like another package manager, a very awkward and limited one.

(Oh, and we have Neon/Containers - KDE Community Wiki)

You also have to install WineZGUI to actually run software installed under Flatpak Wine, which is convoluted. Simply installing software under Flatpak Wine doesn’t create the launcher needed to actually use the software under the Application Launcher menu.

If the official KDE distro is based on LTS releases, than it should conform to the LTS release schedule and use the same packages as LTS releases.

The latest little disclaimer stating that the User Edition is for adventurous KDE enthusiasts is a little underhanded and misleading.

What’s underhanded and misleading about it?

Well, you’re distributing an LTS release that’s not actually an LTS release - With libpoppler-glib8 being one example of a package that’s not inline with LTS releases. Previously it was stated that KDE Neon User Edition was built on a stable base, ideal for everyday users; then we had the update to KDE Neon 6, which borked a number of installs due in part to the libpoppler-glib8 issue (the official Wine page specifically states to downgrade libpoppler-glib8 to install Wine under KDE Neon) - Since then, the KDE Neon download page has been updated from ‘Featuring the latest officially released KDE software on a stable base. Ideal for everyday users.’ to ‘Featuring the latest officially released KDE software on a stable base. Ideal for adventurous KDE enthusiasts.

Blink twice and you could miss the fact that now even the User Edition of KDE Neon is essentially still regarded as a testing platform for KDE devs. Sure, you could go into the since modified FAQ; but while the blurb on the downloads page states that KDE Neon User Edition is built on a stable base, and considering that the FAQ then goes on to state that KDE Neon is a Linux distribution built on the latest LTS release - It’s not until you get roughly 1/2 way down the FAQ page that it’s effectively stated that KDE Neon is an LTS release, but not quite an LTS release; and this is assuming that the unsuspecting user actually looks at the FAQ page considering the carefully thought out wording on the downloads page under KDE Neon User Edition.

I respect everything you do Nate, honestly I do - But the carefully thought out wording is almost inline with Microsoft’s use of wording regarding a ‘Non limited account’ over a ‘Limited account’ when installing Windows as to avoid calling the account a ‘Microsoft account’.

All of this started in roughly Oct 22, when people first began complaining that Wine suddenly refused to install citing broken packages - it was at that point users were quite literally stonewalled with the remark “it’s not a priority for Neon to be compatible with non-KDE software”.

I mean really…What good is an OS without software? You can’t really claim that KDE Neon is based on Ubuntu LTS ‘but not’.

Perhaps I’m nit picking. Perhaps I’m a little bitter that the rollout of KDE Plasma 6 seemed somewhat premature and underhanded (I had no idea I was downloading a full distro upgrade. Normally in such a situation, it’s made clear that the following update is, in fact, a full distro upgrade). Perhaps I’m bitter over the fact that my whole OS install that I’d been running for 3 - 4 years was totally borked as a result of the Plasma 6 upgrade and I was up until 2:00AM trying to get a working OS install up and running again for work the next day as I thought KDE Neon was built on a stable base that’s ideal for everyday users. Perhaps I’m a little surprised that we’re now told that should we use apt to install software “there be dragons”. Or perhaps I’m bitter over the fact that my distro based on an LTS release doesn’t allow me to install Wine using apt - In which case I do respectfully apologize.

However, my point still stands that obvious careful wording does seem a little ‘Microsoft like’. Having said that, I still love KDE Neon and seriously do appreciate and support the work performed by KDE devs.

EDIT: Please don’t take this as a user just being a jerk, as that’s definitely not my intention. My comments are simply vocalized observations from an average Linux user.

1 Like

Lutris complains if you don’t have Wine installed as part of your base OS install, in a way that Lutris can actually access it. I came across this when the whole libpoppler-glib8 package became an issue.

1 Like

Yeah! Apparently the qt6 thing made it clear to the devs that the previous statement was a misleading statement. Consider it as a long term bug of KDE Neon that was just discovered and can’t be fixed, so instead the devs changed the statement.

I guess many of us need to reconsider it. For me, KDE Neon is still ideal for my home’s PCs (desktop and laptop) but the qt6 thing, made it clear to me that I should switch my work’s PC to some other stable distro, probably kubuntu.

Well, the unsuspecting user (ie the one who blindly installs any distro they stumble upon) would switch to some other distro when they eventually find out that KDE Neon doesn’t work for them. :slight_smile:

2 Likes

Which is what I’m currently weighing up. I can either go Kubuntu, which is somewhat laggy regarding KDE DE releases and essentially going backwards regarding my chosen DE in comparison to KDE Neon; or I can go for an Arch based distro, which is somewhat too bleeding edge for my particular use case.

At the end of the day, I was very worried about the update to Plasma 6. For some reason, despite all the praise, I knew everything wasn’t going to go to plan - Little did I know just how wrong things could get.

What’s worse is: I had everything maliciously backed up using kup, which isn’t supported under KDE 6.

Considering the careful wording, I’d consider the unsuspecting user’s actions a result of careful manipulation as opposed to stumbling. The only reasoning I can come up with regarding such careful wording is that Neon beta testers are a very small minority, so the idea is to ‘expand’ those beta testers into the User Edition, which is where the term ‘there be dragons’ begins to hold more merit.

I always understood that by running KDE Neon I was essentially running a rolling release, somewhat bleeding edge DE - and I was OK with that. But to then find that the distinct possibility exists that this distro I’m running that’s based on LTS releases, but not based on LTS releases, may encounter ‘dragons’ should I install software via apt…

…Well that’s got me assessing alternatives. Because as stated, an OS is no good if you can’t run software beyond what KDE devs deem acceptable - Such talk is a little to ‘Gnome’ for my liking.

Based on that paragraph, it seems like you understand exactly where KDE Neon stands between a stable distro (kubuntu) and an unstable one or rolling, if you don’t like the term “unstable”, distro (arch).

Well, I can’t help you on that. KDE Neon like any other distro is what it is. You can use it if it works for you, or you can use other distro if it doesn’t work for you. And this statement is what linux is all about: freedom, which implies freedom of choice.

Not at all. As stated, I’m OK with the fact that I’m running a rolling release DE, and I’m OK with the fact that my base OS is an LTS release - What I’m not OK with since roughly Oct '22 is this agenda that “it’s not a priority for Neon to be compatible with non-KDE software”.

That’s a curve ball.

You’re either LTS or your not, what is it? As far as I’m aware, Kubuntu still isn’t running KDE 6, so is the libpoppler-glib8 issue going to be a problem under Kubuntu with the switch to KDE 6?

It’s LTS base except of the rolling KDE desktop, KDE apps and any dependencies related to that.

I don’t know what the exact problem is, but I guess that newer versions of kubuntu which are based on kde plasma 6 will have to use a newer version of that library as well.

Well if that was the case, there wouldn’t be dragons should I install software from official LTS repo’s using apt.

You can’t be ‘part LTS’.

unless that software requires some older versions of the dependencies that need to be upgraded because KDE Desktop and apps require newer versions of these :slight_smile:

Apparently you can! See KDE Neon for example :stuck_out_tongue:

Which means that KDE Neon is not, strictly, an LTS release - You may as well base it on an interim release, but obviously the devs don’t want to do that as support regarding interim releases is only 6 months.

Do you understand how it’s not the unsuspecting user stumbling their way through distro’s that’s the issue here, the reality is that the chosen wording is very underhanded and manipulative?

1 Like

I agree! It’s ‘part LTS’.

I’m not a lawyer and english is not my first language, so I may not get what you mean here. It seems clear however that we both agreed that KDE Neon is “not strictly LTS” ie it’s “part LTS”

PS: I don’t think that there’s any reason to continue this discussion.