Last time I tried something like that, it was impossible. There are conflicting packages which cannot be installed at the same time, and installation of one causes the other (& it's dependencies) to be removed.

That was a long time ago, but I'd be quite surprised if it were no longer true.

I still currently have Slackware64-14.2 on my daily laptop (for the moment), so I am running 2 distros.

I was there for the beginning of Devuan, but that "environment" turned out to be no different than Debian and most of the others. And I thought that they did things completely backwards by forking Debian *AFTER* the inclusion of systemd instead of grabbing a pre-systemd tree (be it release or commit level version) and building up from there. That just made no sense at all to me.

I actually did a bunch of distro testing when I was leaving Debian and finally landed on Slackware. I tried Void, PCLinuxOS, Arch, a couple of the BSD's plus a lot of others. And was into the without-systemd wiki (is that still around?).

The dependency thing for me is that I like to have most if not all deps fulfilled so that all the functionality of a given package is there. And I currently have to maintain 5 PC's running different programs.

For example; ffmpeg. I know, (for current) just rebuild it, and I do. But I have these (top level) dependencies: "aribb24 celt chromaprint dav1d fdk-aac flite game-music-emu gsm kvazaar libass libbs2b libdc1394 libmodplug libopenmpt opencore-amr rtmpdump rubberband shine soxr srt twolame vo-amrwbenc x264 x265 xvidcore zimg zvbi" and I haven't checked but I'm pretty sure that LM satisfies most if not all of them.

So my personal Slackbuild repository is currently at 453 packages. But that does include my little DE sideproject. It's just a lot easier and saves a lot of time if I can look at that little update icon in the panel and just click, click, updated.

4 members found this post helpful.

Did you look at Alien Bob's ffmpeg packages? They include a lot more than the stock ffmpeg package.
And you think you're leaving? HAHAHAHAAHA!

I ran Arch and Void on bare metal for a time; they're nice distros. I just did a clean install of OpenBSD 6.9 with XFCE on my trusty old T410 Thinkpad. So at the moment I'm running Slackware, Debian, and OpenBSD.

If you find sanity elsewhere, do please call us too!

Again, what you wrote has ABSOLUTELY nothing to do with what I posted. You really should start working on reading comprehension.

The post I replied to stated they didn't understand "why there is so much fixation with running one distro". I explained why I prefer running one distro. Nowhere in my post did I explain why Distro A is better than Distro B. Nowhere did I compare Slackware with Ubuntu. Nowhere did I cover the amount of packages available at one's fingertips.

I simply stated why learning/using one distro is easy than learning/using multiple distros. Do you finally understand the point of my post and why your posts were totally off target?

3 members found this post helpful.

I know Eric's work very well, but I don't use 3rd party repos. Having to rely on someone else is not something that I'm in to. Plus, Eric's builds come with everything baked in. If I'm going to have a package installed I would rather have it installed system wide so that other packages can use it as well without the duplication.

Edit: Plus LM comes with my preferred DE.

But you said:
And how do you propose to be able to do that without relying on someone else?

It'll always be "someone else's" binary. Always. There is no escaping that fact.

If a package maintainer stops maintaining a particular package, you have to wait until someone else picks it up.

It's no different here, except for the fact that you can do it yourself if you so wish.
Yes. And if I'm not wrong, that's what you said you wanted, isn't it?

And it is designed to be installed system-wide, so your point there is not quite clear.

You seem rather confused and unsure of exactly what you want.

1 members found this post helpful.

It is different. Someone else may maintain the build script used to build the package, but if the package needs to be rebuilt does the script maintainer rebuild it and upload it to a 3rd party repository or even the main distro repo?

No. download Eric's ffmpeg, open it up and tell me where libass is installed system wide, or x264, or x265, etc. It is not. But it is a dependency that Eric uses to build ffmpeg.

Eric's ffmpeg (as with many of his packages) have a lot of dependencies included statically, not dynamically. This allows one to simply install ffmpeg without needing to install all the dependencies ffmpeg needs.

It makes it simple for someone who simply needs ffmpeg (or vlc), but not for someone who wants to use those libraries with other programs.

4 members found this post helpful.

Firstly, the main distro repo can be accessed via slackpkg without adding anything to a stock installation. You can use slackpkg to update a default installation with very little effort.

Secondly, there are several repositories which are maintained for 3rd party packages in Slackware.

You can access them using standard slackware tools if you install slackpkg+.

So, no I don't believe that it is any different at all.
Ah. Now I see what you're saying. Yes, Eric builds some packages statically, so many of the dependencies for those will not be available system wide. You are quite correct there. But this enhances portability of the binary package, because it ensures that the binary can run on systems with different library versions, etc. For some of those dependencies, I'd question their value outside of ffmpeg, or whatever else they're being used for.

Except that I said that I have 5 computers running different 3rd party packages (for Slackware) which is what I need updated.

Yea, but I don't need portability. I have other packages that have some of the same dependencies as other packages so it makes no sense to install a bundled build of any given package. If I wanted that I might as well install windows.

Slackpkg with slackpkg+ can do this. I have three computers running different 3rd party packages. I keep them up to date using slackpkg with slackpkg+. I use a tailored slackpkgplus.conf for each each computer.

1 members found this post helpful.

Yep. Debian added opendoas shortly before entering their new version freeze, and the binary was built without timestamp persistence by mistake. Now, that's the default way of building it, and it could be argued that it's the best way, security-wise (only OpenBSD has the kernel API to make password persistence work without timestamps). But thanks to the freeze, the only way to get password persistence for doas on Debian - and, presumably, the Debian derivatives - is to build from source.

Dealing with this kind of stuff is arguably simpler when the solution is to grab the SlackBuild and throw parameters at the problem.

I am one computer short of five running things on Slackware.

Can't help much here but so far I've learned:

1. binary repos of SBos are a godsend if in a pinch - saved me quite a day on occasion (kudos to slackonly)
2. sbotools save me most of time due to most of my machines are Intel Sandy bridge (how value depreciation turns tables!) (kudos to pink-mist)
3. there is that golden moment to build most of packages from SBo, once past that, good luck pulling off some builds (package inter dependencies resolution is a deep dark rabbit hole to wade after a while with huuge dragoons at the dark rock bottom)
4. Yes! Slackware made me pull hairs at a moments, but never ever (and BOY did i do strange and out of this world things with computers) let me dry in the sun - contrary to several other distros i tried. Kudos to Patrick, our ever sane captain

So in the end:
The alone concept of "this is how far the distro is going (draws a line) and we're not crossing that" is in my view a thing that makes one distro great and the other fail over it's nose at certain point down the line. Historically, commercial OS-es drew that line at one place, most Linux distros on another, some even at no place...

Slackware IMHO draws that line most similar place to that few big players in the arena, and track record shows just how far some sanity early on can take you.

1 members found this post helpful.