why no build yours with

??

you know ffmpeg its a dependency for mplayer and ffmpeg its build with samba ??

You know what are you doing ?

2 members found this post helpful.

Yes, I use my own builds of mplayer & ffmpeg

After removing samba from my systems, ./configure autodetects that samba is not present
thereby configuring and building mplayer & ffmpeg from source without samba being required.

IMO, it might be useful for those not adept in building from source to have...

extra/MPlayer-without-samba
extra/ffmpeg-without-samba

(along with any other programs that might be in the slackware repository which require samba)

I see no reason to not install Samba and it's not that simple to have a Samba free system. No offense intended, but here I smell another pure-ALSA fiasco...

Anyway, you shouldn't convince me, but the Boss.

So, you estimate that there are many Samba hatters around, or it's just your personal hate toward Samba?

Honestly, for me this kind of attitude is a novelty.

2 members found this post helpful.

I don't hate samba.

It's just I see no need to have it taking up space on my HDD when I do not need it. ;-)

1 members found this post helpful.

Maybe you just don't know what it does, or how to use it? Samba is a powerful tool which brings a ton of flexibility, particularly if you have any non-Linux machines on your LAN. As an example, my wife has a work-issued Windows laptop, one kid has a school-issued Chromebook, the other has a school-issued Mac. They can all print, access files and stream media via the Slackware machine which I use for work... and that's because of Samba. I also have a so-called "smart" TV which connects to the Samba share and can play media. It's quite a handy thing, even for a home network.

You can also use it to create AD domains, which I'm still experimenting with... but Samba gives the ability to do that without having to fork out megabucks for Windows Server and Client Access Licenses.

It's required by ffmpeg and mplayer because they can both stream media off Windows-based file servers. Why you'd remove that kind of functionality is not clear to me... unless you're 100% sure that you're never going to encounter a Windows share you want to stream media off (for example: at a friend's house).
I'd suggest that people who are not adept at building from source are exactly the kind of people who should be running a full installation of Slackware, and using it to learn how to build from source... and then they can use their new skillz to remove all the functionality they like.

5 members found this post helpful.

In Slackware, all packages are guaranteed to work if and only if all packages are installed. That's nothing new and unlikely to change anytime soon.

4 members found this post helpful.

Adding an external library has the exact same effect on system stability as removing a shipped library, and there's no way around that.
This is why such guarantees are very hard to make:

1. Adding nvidia has unforeseen consequences, as some packages link to libglx.so from mesa and some link to libglx.so from nvidia.
That is, if you compile something with nvidia installed and package it, then nvidia will be a requirement for the package. Therefore, unsupported.

2. If library removal makes the system unsupported, then so does library addition.
If one already adds an external lib, and makes the system unsupported with it;
Library removal would not make the base system any less supported than it already is.

2 members found this post helpful.

libglx.so? It's something the x server uses. Maybe you mean libGLX.so. In 15.0 programs already link to libGL.so, libGLX.so, etc of package libglvnd.

ChangeLog.txt:

1 members found this post helpful.

There's no way to know this is true for certain, or that it'll stay true in the future.
It's a workaround for a mess which was not caused by Slackware. Same mess, one could easily produce by adding a bunch of libs.

The samba package takes less than 100 MB of disk space when installed. For a spinning drive, that would equal a value of about 1.5$ ( https://www.backblaze.com/blog/hard-...-per-gigabyte/ ), for an SSD about 3 times as much.

Yes, it would be possible so spend time on selecting which packages to install and recompile packages to get rid of dependencies, but what is your time worth? If you want a Slackware installation without Samba you probably also want to skip other, bigger, not used packages. In my experience such an installation will require a lot of time figuring out why things does not work in lack of dependencies.

regards Henrik

1 members found this post helpful.

$0.0015

2 members found this post helpful.

When uninstalling the Nvidia driver you are given the option to return things to as they were before you installed the driver. After that point I guess it is up to the user to recompile any affected packages.

Sorry.... I had no idea that such a simple request would result in such a complicated controversy. ;-)

It's not "a simple request" as you think.

Because IF our BDFL accepts to ship an alternative Samba-free set of packages, there are a lot of packages which should have an alternative building. Plasma5's KIO slaves, Konqueror, Dolphin and Krusader, XFCE's Thunar and friends, heck! even the Midnight Commander. And for what? Because you do not need Samba?

BUT, there are also the guys who dislike PulseAudio, elogind and Xorg. What shoud our BDFL do? To ship in /extra also packages for them? And what he should do for those people who dislike elogind and Samba, but loves PulseAudio?

How many alternative trees should ship our BDFL on /extra according with you?

4 members found this post helpful.

Then that's an exercise left to the user, as Pat puts it. I do digital audio. Pulse is a liability, so I built things I need without it before pipewire, and am strictly pipewire-only these days. Before the preempt=dynamic kernel was shipped, I built mine for RT. Hell, I remember back in the early 2000's, I had to rebuild libasound, because one of the languages I used needed something that the stock build didn't provide. If your use is an edge case, you get used to building the things you need, which is a strength of Slackware. (Try doing all of that on ubuntu without serious breakage.)

4 members found this post helpful.