Having dependencies problem on Maui Linux

[4goodapp]

I got this error:

The following packages have unmet dependencies: python3-pyqt5.qtwebkit : Depends: python3-pyqt5 (= 5.5.1+dfsg-3ubuntu4) but 5.5.1+dfsg-3+16.04+build2 is to be installed E: Unable to correct problems, you have held broken packages.

trying to install python3-pyqt5 alone tell me a newer version is already installed.

[kanishka-linux]

I've tested it on both ubuntu and mint, and it was working fine. The problem can happen due to partial upgrade. First properly upgrade the system using 'sudo apt-get update && sudo apt-get upgrade' and then use 'gdebi' from command line to install the package. Don't use gui based installer. After that, if there is some problem, post output of gdebi.

EDIT: If kawaii-player has been installed as broken package, then first remove it using synaptic package manager, before using above mentioned method.

[4goodapp]

The problem can happen due to partial upgrade

Probably

Am using Maui Linux, am afraid that sudo apt-get upgrade bring me some surprise/instablity so, I avoid it as much as I can.

I've install it via gdebi via CLI but facing the same issues.

Another question, why not simply package it with all dependencies included?

Nice app btw :)

[kanishka-linux]

if you've ever used 'sudo apt-get update', but have not used 'sudo apt-get upgrade', then it means that system is already prone to instability. Therefore use both simultaneously.

I just checked about Maui linux, and it seems to be rolling release distro. In any rolling release distro, it is necessary to do upgrades at regular interval, otherwise system might break sooner or later.

By the way, if you still want to test the application, then you can create live bootable usb drive of ubuntu or mint, and then install it on live usb session without having to install it on hard drive.

Nice app btw :)

Thanks

EDIT: It is possible to package the application with all dependencies, but the resultant package becomes very large in size which I tend to avoid.

[4goodapp]

Maui is based on KDE Neon, and that's what I was using before. It update automatically itself, creating some instablity... and one day, I couldn't even boot . Didn't even bother to fix it. That's why I use Maui now. Updates are not forced. Too much updates bring nothing but instability in my experience. That's why I use Windows (10) any more.

By the way, if you still want to test the application, then you can create live bootable usb drive of ubuntu or mint, and then install it on live usb session without having to install it on hard drive.

Yeah but that's too much for me. Will keep my eyes on Kawaii though. I like the UI.

[kanishka-linux]

Too much updates bring nothing but instability in my experience

That's true, in most of the cases. Hence, I normally suggest LTS based distros such as ubuntu or mint to most of the users, if they want stability. In rolling release distros, it's good to use only LTS based linux kernel, for overall system stability. For rolling release I normally prefer ArchLinux based system, but I think debian testing might be also good choice.

Yeah but that's too much for me.

I can understand. It's too much basically for anyone.

[4goodapp]

Well That is weird, I though it was an LTS based distro. I have tried Arch with Manjaro but, updates every time is just not for me. I may give Debian (stable LTE) a try though.

[kanishka-linux]

Since, last few releases, a self contained binary has also been released for the kawaii-player, which you can find here. I'm closing the issue. By the way, thanks for bringing attention to create binary package. It seems, good number of people prefer downloading binary version.

[ShalokShalom]

By the way, thanks for bringing attention to create binary package. It seems, good number of people prefer downloading binary version.

Yeah, since most distributions struggle to ship solid packaging strategies, imho. In my experience, the rolling KaOS ships at least such a stable experience as LTS distros.

Its downside is, that lot of 'exotic' programs like Kawaii are up to the user to build and maintain.

[kanishka-linux]

Yeah, since most distributions struggle to ship solid packaging strategies, imho.

In fact, there is so much diversity in gnu/linux systems that it is almost impossible for each of them to agree on a unified packaging strategy, as every distro has its own separate way of doing things. But this lack of unified packaging can be a headache for both users and developers. In case of creating binary also, there is no common agreement and therefore we now have variety of binary formats like flatpak, snap, appimage. Sometimes, I do not understand, how developers are going to manage all this variety. It will be great, if all the major distros come together and hammer out some common format and naming convention for packages, which will make life easier for users, developers and maintainers.

Its downside is, that lot of 'exotic' programs like Kawaii are up to the user to build and maintain.

yes, that's true.

[ShalokShalom]

I mean more packaging at all. They are often focused on what their userbase demand, instead of what makes sense. So, each major ships each desktop, regardless that some of them have to stay behind, since all the versions in the basic system work differently with the individual toolkits, and so on, and so on.

Debian think its sane to split each package into 4 million pieces and the most distros fail to update essential parts of their system for years, which slows down the whole process, including issue reports and so on.

There are dozens of other issues and I am pretty sure, that the solution is to choose a modern distribution.

Habitat is by the way a nice binary format :stuck_out_tongue_winking_eye:

[kanishka-linux]

Debian think its sane to split each package into 4 million pieces and the most distros fail to update essential parts of their system for years, which slows down the whole process, including issue reports and so on.

yes, this is something I've also noticed.

Habitat is by the way a nice binary format

This is the first time I've heard of it. Is there something special about it that makes it different from other formats?

[ShalokShalom]

Yes, since it offers support for all the major platforms, the build scripts are super easy to intelligible, you can create Docker images from it and its written in Rust.

I once created this sheet, its currently incomplete:

[kanishka-linux]

I once created this sheet, its currently incomplete

nice work! that chart looks great, and (Habitat) support for almost every platform - that is something really special. I'll certainly look into it, if it has some good documentation. Actually having diversity is also sometimes good, because of which we get to choose from many options and sometimes we stumble upon rare gems.

[ShalokShalom]

Yeah, i looked on this post at Reddit and felt immediately that Habitat is such a hidden gem.

Its downside is, that its desktop support is lacking behind that one for the services, they clearly focus on servers.

The thing is, that the tech behind Habitat is totally capable to ship both, its imho simply a question of the community.

I mean, there are a lot of nice, helpful and skilled people in Habitat, so I hope they get consciousness.

The most of my issue reports got ignored and/or closed without a solution for me. A huge stack of those is about the documentation.

Currently is it imho the case, that they refuse everything, what is not part of their vision. To sum it up: Habitat shows clearly the difference between open source and free software.

[kanishka-linux]

Its downside is, that its desktop support is lacking behind that one for the services, they clearly focus on servers.

If their vision is on servers, then it will certainly affect their desktop support.

A huge stack of those is about the documentation.

I just briefly took a glance at its documentation, and I found that its main packaging file is similar to that of PKGBUILD, but I couldn't find a straightforward way to create binary. Maybe I'll have to look at it carefully afterword. But documentation is really a problem with most of the open software that can make even a good piece of software look bad.

[4goodapp]

...which will make life easier for users ...

One thing I learned in the Linux world is how they don't care about simple users experience. It's like they want everyone who use Linux should know how to use a terminal. Of course, we have very few exceptions here and there but that's it.

At least, AppImages work everywhere, without the need to install anything else.

...

This Habitats thing seems interesting. At least, until I read about this server thing. Never hear about it, same for Nix.

---

And did you guys notice that by trying to have an unified packaging for all distros we're actually about to get more unified packaging than no-unified packaging?

[kanishka-linux]

@4goodapp

It's like they want everyone who use Linux should know how to use a terminal.

linux ecosystem is built by people with hacker like mindset, therefore terminal has been given more importance here. But still in last few years, ubuntu and its derivatives have done good job by minimizing use of terminal for normal users.

by trying to have an unified packaging for all distros we're actually about to get more unified packaging than no-unified packaging?

I couldn't get the point. can you elaborate more?

[ShalokShalom]

One thing I learned in the Linux world is how they don't care about simple users experience.

Yes, there is still a lot of stuff do to, like a all-in-one installer for Linux distributions. Something like that is important and easy to create, while the majors seem to act blind.

But still in last few years, ubuntu and its derivatives have done good job by minimizing use of terminal for normal users.

Mandriva did this years before Ubuntu.

And did you guys notice that by trying to have an unified packaging for all distros we're actually about to get more unified packaging than no-unified packaging?

Who does this, then? There are very few people, which I trust about packaging. See the comment above.

[kanishka-linux]

@ShalokShalom

Mandriva did this years before Ubuntu.

Oh that bring back some old memories. I almost forgot about Mandrake linux. I personally never used it, but got to know about it from friends. I never understood, why despite being considered as user friendly, it failed to get large user base.

[ShalokShalom]

Drivers.

[kanishka-linux]

Drivers.

Oh, I should have guessed that. It was the main problem back then with almost every distro.

[probonopd]

At least, AppImages work everywhere, without the need to install anything else.

That's because it was explicitly designed so that "it just works" and distributions don't have to "agree" on it.

[ShalokShalom]

Yeah, AppImages are quite nice. Especially to add specific packages, which are absent in the official repo. Its a nice addon to a current package manager.

[4goodapp]

I couldn't get the point. can you elaborate more?

Like before, we had (and still have) rpm, deb, and i guess Arch's package, etc... and by trying to solve that diversity with one unique packaging, we end up with snap, flatpack, appimage (my favorite) and other i don't know... habitat etc...

and distributions don't have to "agree" on it.

Haha, I like that one.

[ShalokShalom]

Like before, we had (and still have) rpm, deb, and i guess Arch's package, etc... and by trying to solve that diversity with one unique packaging, we end up with snap, flatpack, appimage (my favorite) and other i don't know... habitat etc...

On whose decisions do the community rely then?

This is the issue. Which strategy? How much split? Focus on which GUI? I use KaOS since 4 years now and was a distro jumper for about 2 years before.

From what I can tell you: Focus matters.

Most distros focus on GTK+ and put KDE on top of it, regardless to the compability and this leads to the situation where each and every part of the fundamental system is optimized for the GTK+ stack, which leads to a buggy KDE experience on these systems.

In order to achieve this goal of one united package infrastructure, is it in my opinion fundamental that we respect this aspect and some others too.

Headers split from the application itself? Whats about other parts? Split them as well?

Most people who decide for a distribution tend to show less interest about packaging itself, so how to convince these people?

So, what I can see as a solution is, that we use one package management which get used for the own OS and is shareable for all the others in the same time.

Atomic is a potential candidate? AppImage is meant as an Add-on. Habitat is focused on server software. Snappy is non-free on the server side.

I see it as a possible solution, to include other operating systems like Illumos and the BSD family. My intention says that ;)

[kanishka-linux]

@4goodapp

Like before, we had (and still have) rpm, deb, and i guess Arch's package, etc... and by trying to solve that diversity with one unique packaging, we end up with snap, flatpack, appimage (my favorite) and other i don't know... habitat etc...

ok, that is some alternate approach to look at things. If we look at current implementation of self contained binaries, then we'll see that they are not meant as a replacement to traditional package management. These binaries are good for installing some occasional packages that are missing from official repositories. But I agree, it's still a good start to manage diversity.

@ShalokShalom

Most distros focus on GTK+ and put KDE on top of it, regardless to the compability and this leads to the situation where each and every part of the fundamental system is optimized for the GTK+ stack, which leads to a buggy KDE experience on these systems.

It is difficult to optimize any distro for two different toolkits. However I found that KDE based desktops support GTK+ apps much better than vice-versa.

So, what I can see as a solution is, that we use one package management which get used for the own OS and is shareable for all the others in the same time.

This is a good idea and I also would like to see something similar like this to get implemented. In order to do this, everybody needs to agree on some common standard for packaging, like at least some default configuration file (similar to either PKGBUILD of arch or 'control' file of debian) format for packages or way to split dependencies, that can remove lot of ambiguity. But I know, this is the most difficult. And I don't think we can depend on self-contained binaries to solve this issue.

[4goodapp]

Atomic is a potential candidate?

Atomic? is that one part of the new?

So, what I can see as a solution is, that we use one package management which get used for the own OS and is shareable for all the others in the same time.

This is a good idea and I also would like to see something similar like this to get implemented. In order to do this, everybody needs to agree on some common standard for packaging, like at least some default configuration file (similar to either PKGBUILD of arch or 'control' file of debian) format for packages or way to split dependencies, that can remove lot of ambiguity. But I know, this is the most difficult. And I don't think we can depend on self-contained binaries to solve this issue.

I think this would be awesome too but, I wonder if that will ever happen though. I mean, what will be the point of having different distro if that happens? Cause the only difference I see in Linux distro is different packages. Along with wallpaper, color scheme sometimes. That's it. Oh and of course, pre-installed software which don't make much sense.

[ShalokShalom]

If we look at current implementation of self contained binaries, then we'll see that they are not meant as a replacement to traditional package management.

You describe the usage of these technologies. When you look at the chart, can you see that several package management systems offer both, system internal libs and shipped ones in the container.

It is difficult to optimize any distro for two different toolkits.

Thats why I suggest to focus on one. How many distros do that?

However I found that KDE based desktops support GTK+ apps much better than vice-versa.

You might be interested into this one: https://www.youtube.com/watch?v=ON0A1dsQOV0

some default configuration file

Indeed, I choose PKGBUILDs from KaOS for that, porting to Habitat is basically a question of 'find and replace' some variable names, the removal of some redundant lines and so on.

Both use bash scripts, they look very similar:

way to split dependencies

Dont split them, easy as that. Ship as upstream does. This is, how upstream tests and its transparent.

[kanishka-linux]

@4goodapp

what will be the point of having different distro if that happens? Cause the only difference I see in Linux distro is different packages. Along with wallpaper, color scheme sometimes. That's it. Oh and of course, pre-installed software which don't make much sense.

you've raised a valid point here. I'm not saying same package manager for all, what I'm more interested in is some form of interoperability among various package managers based on some default common agreement, so that we can easily port software available in one distro to other. There is no doubt that package manager gives identity to any distro, but even if two distro share same package manager they can still distinctly identify themselves (Like Ubuntu and Mint; or Red Hat and Centos).

@ShalokShalom

You describe the usage of these technologies. When you look at the chart, can you see that several package management systems offer both, system internal libs and shipped ones in the container.

I looked into the chart again, and it is interesting that some of them provide support for both. I'll try look into it.

Thats why I suggest to focus on one. How many distros do that?

I think that, focussing on one is not good from the point of view of users, since there are really good software written in both toolkits, and normally may users want them irrespective of any distro they are using. I still use gtk software in kde, and kde software in gtk environment. Like, okular is such a nice pdf reader that I install it on many occasions on gnome based systems, and pcmanfm is such a fast file manager that I always install it on every distro even if it is kde based one.

Dont split them, easy as that. Ship as upstream does.

That is some nice approach, and will minimize all dependency related issues.

[ShalokShalom]

I looked into the chart again, and it is interesting that some of them provide support for both. I'll try look into it.

I think the question is here, how finely adjustable they are: Can I set "try to use system libs and fallback on those ones in the container, if not available?" or even: "Can I get a package, which comes with exactly the dependencies, which are not included in my system" and so on.

I think that, focussing on one is not good from the point of view of users, since there are really good software written in both toolkits

The thing is, that you can write one distro per desktop environment and Container protect some conflicts anyway.

and pcmanfm is such a fast file manager

You mean fast in the sense of usability?

I think the sane way is to create applications, which you can configure in different ways. So you develop one application for different cases. Otherwise develop the whole community on 10 different places. This is, what i love so much about Qt/KDE.

[probonopd]

Well... distributions are great for the base system (compare to: Windows, macOS) whereas the application bundling systems (AppImage and friends) are great for providing fresh applications straight from the authors, that run on top of the base system.

Distributions initially assumed they could distribute not only the operating system but also every application that runs on top of it, and lately are recognizing that this will not scale.

[ShalokShalom]

@4goodapp

Atomic? is that one new?

2 Years: https://www.projectatomic.io/

I mean, what will be the point of having different distro if that happens?

First of, you would be astonished, when you see how much is different.

The whole LFS process, as an example. Basically all the decisions about which tools get used, both visible and invisible. Hardware detection, init system, distro-specific tools, default settings..

Then, packaging includes a lot of questions like: Which package to ship when and with which one in combination?

@probonopd The thing is, that they like to ship everything instead of a sane subset. demm develops 2200 packages alone, Debian gets packed by some dozens, maybe hundreds of packagers. There is a reason behind. And the funny thing is, that in KaOS is always nearly everything up to date, while Debian is out of date. And that with at least the same stability.

[kanishka-linux]

@ShalokShalom

The thing is, that you can write one distro per desktop environment and Container protect some conflicts anyway.

this might be a possible approach to solve the issue, if containers can properly integrate themselves with overall desktop.

You mean fast in the sense of usability?

yes. After all it was designed for lightweight desktop environment such as lxde. I've tried all types of file managers but no one comes near to it when it comes to performance, except may be terminal based file manager like ranger.

@probonopd

Well... distributions are great for the base system (compare to: Windows, macOS) whereas the application bundling systems (AppImage and friends) are great for providing fresh applications straight from the authors, that run on top of the base system.

Very relevant point noted. It seems having separate base system and separate application bundling system, might solve lot of problems.

Distributions initially assumed they could distribute not only the operating system but also every application that runs on top of it, and lately are recognizing that this will not scale.

Good thing about distributing base OS along with every application is that applications integrate well with the overall distribution and provide really good user experience (like proper integrated theming, unified configuration directories, nice way to update applications securely etc..). But surely I agree that all of this comes with some scaling issues - which AppImage and other self contained binary formats are trying to solve.

[ShalokShalom]

I've tried all types of file managers but no one comes near to it when it comes to performance, except may be terminal based file manager like ranger.

What I like about PCManFM is that it offers the applications also, like Finder in macOS. Dolphin can be configured, to look and feel like PCManFM, otherwise. That is, why I like to write something for Dolphin, which allows to launch it in different configurations. What do you like in PCManFM in specific?

It seems having separate base system and separate application bundling system, might solve lot of problems.

The thing is, that this doubles and triples the memory consumption, while I guess that this downside is currently one of the most cheap ones. AppImage is easy to package, this is one of the unheard benefits? Fresh packages are also available in rolling distros, so I see the benefit of AppImage here again somewhere else: One packager can enjoy each user, namely the software creator.

I think we can bring it down to the point: The core maintainers will succeed to pack their base system - nothing will convince them to use one shared repo.

And otherwise will one such central place make sense to appear as the place for Linux applications.

proper integrated theming

What do you mean? When you ship an application, choose the configuration of the OS, how the theme looks like?

unified configuration directories

Habitat does that in the application itself. All in Habitat is stored and configured in the application package itself. This is why a lot of stuff becomes redundant to write for the package creator.

[ShalokShalom]

@probonopd Subsurface released new minor versions, who should run now on systems without SELinux. You might like to update that one on your page.

[probonopd]

Thanks @ShalokShalom, done.

[probonopd]

Fresh packages are also available in rolling distros

That doesn't help if you are, say, an employee of a corporation that is using a Long Term Stable desktop (on which you don't even have root rights).

[ShalokShalom]

That doesn't help if you are, say, an employee of a corporation that is using a Long Term Stable desktop (on which you don't even have root rights).

Which is a failure of the company, because it use such a concept. Our infrastructure is since 5 years on KaOS. Which means build server, repository and so on. The online package viewer use old PHP, so this one is on CentOS.

So yes, a lot of companies use very old operating systems, for different reasons. Sane packaged rolling distributions are possible in nearly all cases.

Thanks @ShalokShalom, done.

Thanks a lot dude. :smile:

[kanishka-linux]

@ShalokShalom

That is, why I like to write something for Dolphin, which allows to launch it in different configurations. What do you like in PCManFM in specific?

Dolphin is amazing file manager and I've used it for many years. I used to install it on every desktop environment without thinking about dependencies it used to pull along with it. When it comes to features and customization, I don't think anyone can stand a chance against it even today. It's only downside was its startup time, which has improved a lot in the past but it is still not instant. Once I started using pcmanfm, I was able to do everything that I could do with dolphin plus instant startup time. I think, dolphin should keep running one instance in the background once KDE session has been initialized, to improve its startup time.

proper integrated theming

Last time I used some self contained binary, they did not follow default theme of desktop and were looking like applications from windows 98 era.

What do you mean? When you ship an application, choose the configuration of the OS, how the theme looks like?

There are too many desktop environments in GNU/Linux systems, will packager be able to provide configuration for each one of them?

unified configuration directories

Habitat does that in the application itself. All in Habitat is stored and configured in the application package itself. This is why a lot of stuff becomes redundant to write for the package creator.

In the case of kawaii-player, it creates a config directory (in .config) and stores all user generated information in one place. For example: database about multimedia, temporary cache folder, and many folders are generated on the fly to store information about users' collection which users can change at their will. It is necessary that users should have power to manipulate these config directory to fix some minor issues on their own. Moreover, the application is library manager, therefore it is also necessary that it should have power to scan some default locations decided by users for availability of multimedia. It also invokes external applications like ffmpegthumbnailer to generate thumbnails, which are also stored in config directory of the application. Does Habitat allow all such extensive privileges to manipulate config directory of the application? If it does then I'll certainly give it a try.

Another important aspect people talk about sandboxed application is that they are much secure. But if libraries packed by application are outdated then it can create many security holes. I know some of these sandboxed applications allow updating, but imagine if you've some hundred such apps and you need to update each of them manually, it looks cumbersome; and allowing every binary application to auto-update itself looks fishy and makes me remind me of how things are done in proprietary operating systems. In normal package manager, we just need one command and entire system gets updated, which is much better from the point of view of security.

In think packaging in GNU/Linux systems is already very mature and advanced one, only it needs some coordination and tweaking. Today app centre/ software centres are common in most of the proprietary systems, and I'm hundred percent sure that they have borrowed this idea from package management/software repository in GNU/Linux systems.

[ShalokShalom]

It's only downside was its startup time, which has improved a lot in the past but it is still not instant.

Its about half a second here.

There are too many desktop environments in GNU/Linux systems, will packager be able to provide configuration for each one of them?

Qt allows to use the native style. A few people force another style, like Tiled. Is it different with GTK+?

Does Habitat allow all such extensive privileges to manipulate config directory of the application?

The config directory of the application is in Habitat, so I guess yes. You can ask the devs here.

if you've some hundred such apps and you need to update each of them manually

https://www.habitat.sh/docs/run-packages-update-strategy/

In think packaging in GNU/Linux systems is already very mature and advanced one, only it needs some coordination and tweaking. Today app centre/ software centres are common in most of the proprietary systems, and I'm hundred percent sure that they have borrowed this idea from package management/software repository in GNU/Linux systems.

Windows and OS X/macOS both provide "install any app, when ever you want" and Linux/BSD "secure, central place for all software" since decades.

[probonopd]

Which is a failure of the company, because it use such a concept.

Need to disagree, a company (or school, or university) needs a stable long-term reliable OS, and will often not give users root rights. We need solutions that allow users to use bleeding-edge applications nonetheless, without root and without being able to corrupt the system. But hey, let's not get too off-topic here.

[ShalokShalom]

Yes and the thing is, that my experience shows that a carefully shipped rolling system is so reliable as a LTS distro. I often run into issues with Debian "so called" stable with KDE and Kubuntu, Mint does its job more reliable compared to other Debian based distros, in my opinion, I experience less bugs there.

My job is it to install operating systems on casual consumer devices.

People are most often stressed, since they thing their experience in Manjaro and other distros is deeply connected to the rolling nature of those. The opposite is true:

Rolling distros can often update more quickly and reliable, since backporting is critical!

And the update process is anyway part of the job of a sysadmin. ZFS on Linux, btrfs and other solutions make it easy to rollback, if anything happens.

[kanishka-linux]

@ShalokShalom

Its about half a second here.

If you've 30-40 firefox tabs, 2-3 instances of file managers, 3-4 terminals, text editor geany, dictionary are open and some music in the background; and if you want to open new instance of dolphin now - then also is it half second? As far as pcmanfm is concerned, even if system is fully burdened it can be opened instantly. And it's performance suffers not a even a bit on either low end machines with 2GB ram or older netbooks (I test and optimize my applications for machines with lower specs also).

Is it different with GTK+?

I don't have much idea about this.

https://www.habitat.sh/docs/run-packages-update-strategy/

As you've already mentioned that their focus is on servers, and that strategy surely looks like for servers with lot of new terminologies to learn. It can be good for system admins or maintainers, but from the point of view of users and developers, it is too much for them - when you've option to update the system with just one command.

Windows and OS X/macOS both provide "install any app, when ever you want"

I was talking about dedicated trusted software repository. "install any app, when ever you want" - this can't be counted as installing from central software repository. Moreover I was making comparison with closed proprietary systems vs open/free systems - therefore, I was not at all discounting BSD systems.