SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I wouldn't mind having the dependencies up to flatpak included with the distro. Makes my life simpler when building webkit2gtk and the rest of gnome that's on top of that.
Sure the flatpaks themselves are built on whatever system and can taint a slackware system and live outside of the slackpkg management system. Should that limit the addition of at least the underlying dependencies which have other uses too?
If people use flatpaks, they will have to expect to get support from the flatpak producer, not the distro at that point, or is that not true? I don't use flatpaks themselves much other than just trying a couple to see they work over the years. I do use the underlying dependencies bubblewrap, appstream, xdg-desktop-portal-* and would like it if those could continue to work well enough on slackware into the future.
To be honest, in this great world of Linux distributions, absolutely nobody provides a huge kernel with all these built-in modules
Sorry to be back on this after many days, I've been busy. I made a big effort on myself to avoid bringing in the topic of what other distributions do, because it would easily trigger you know who on you know what But yes. Almost all distributions provide a simple basic kernel and require to create an initramfs with boot device and file system drivers. Most of them do it automagically without the user needing to know anything about it.
Quote:
Originally Posted by marav
Are you suggesting that Slackware users are less skilled than all other users?
No, but I was frankly surprised to find out that so many people have always used the huge kernel and never learnt to deal with initrd, to the point that dropping huge kernel while leaving the generic one the way it was caused distress. Building initrd is something that has been normal for me probably since the times of kernels 2.x , I think. O:-)
Flatpak is a very good tool, and very very usefully special for young people.
It work fine in a Slackware system, personally I use it last 2 years and i m very happy with it when i need it.
If it will be in Slackware-15.X.iso or not, its not big deal for me BUT I think a flatpak gui and plasma6 announcement, will give +100 for new slackware desktop users.
But thats our BDFL job to decide if...needed.
I use flatpak's as well on my kids computers. But for the management system I still use slackpkg and slackpkg+ because I maintain 3rd party repo's on my network.
Which does not mean you would see this in Slackware any time soon (in fact, Pat Volkerding always seems to skip packaging Discover, probably because it is useless without also providing a backend such as Flatpak).
Which does not mean you would see this in Slackware any time soon (in fact, Pat Volkerding always seems to skip packaging Discover, probably because it is useless without also providing a backend such as Flatpak).
Discover mainly needs packagekit, with its set of dependencies
I have no interest in flatpak, but that being said if it is considered - maybe it would be best to put it in /extra and not actually installed during the installation of the distro, but thats my
Discover mainly needs packagekit, with its set of dependencies
It does not require PackageKit, this is just an optional dependency, just like Flatpak. Of course you would need at least one of those backends to make Discover useful.
If you install either, or both, when you compile Discover it will find these installed and enable their support.
Last I checked, PackageKit does not support Slackware. At least not in a useful way.
It does not require PackageKit, this is just an optional dependency, just like Flatpak. Of course you would need at least one of those backends to make Discover useful.
If you install either, or both, when you compile Discover it will find these installed and enable their support.
Last I checked, PackageKit does not support Slackware. At least not in a useful way.
It's not useful to be included in Slackware, it's just a 3rd-party software, right ?
So let's leave it where it is
It's not useful to be included in Slackware, it's just a 3rd-party software, right ?
So let's leave it where it is
Why so rude? You don't like to be contradicted?
Discover is an integral part of KDE Plasma: https://download.kde.org/stable/plas...-5.27.9.tar.xz but without either Flatpak or PackageKit it is indeed non-functional. Both are compile-time dependencies so Pat cannnot just compile Discover and let us install a backend from someplace.
With both Flatpak and Discover installed, you have a nice graphical interface including search, install and update of all the available software on FlatHub.
So we don't need Flatpak, because it's in Alien's repo.
The question then becomes: How much a part of 15.0, ~Current & 15.1 is Alien Bob's repo? .
I notice "It's in Alien Bob's repo" advanced as a reason to keep a lot of stuff out of releases, which is fine. At the moment, we have the choice of treating Alien Bob's repo as an extra package directory of any install iso. But Alien might seek greener pastures one day, as he is entitled to do. We'd need a different shape on the install dvd then!
Shouldn't Alien's popular downloads be looked at for inclusion into the main dvd?
It was not my intention
Let me explain
I think people first have to :
- make an SBo
- deal with dependencies and the possible mess that can result from them (i.e python/perl/ffmpeg/llvm etc.)
- deal with possible breakage after each update
- deal with patches
To clearly understand how "This could be a great addition". may finally not be
Shouldn't Alien's popular downloads be looked at for inclusion into the main dvd?
Slackware consists of the packages included on the official Slackware installation media (or isos nowadays). Then there are third party sources like Aliens packages, slackbuilds.org and other sources.
What you choose to install depends upon your needs and which sources you trust. Most third party software from slackbuilds.org are built from source. Some people find software where you can study the source more trustworthy. Alien provide prebuilt binary packages for Slackware, usually together with SlackBuild scripts and sources to study, much like Slackware itself.
Even though Alien does a great job to provide his packages, having access to those third party packages are not really the same as being included in Slackware. Most of all, third party packages might not get security updates in such a good way as official Slackware packages. This is my main reason to wish that multilib was included in Slackware64 as it once was in Slamd64 instead of a third party provider like Alien Bob (Eric Hameleers).
Such concerns might not matter much for those who want Flatpak as it by definition is a tool to install binaries from third party sources.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.