Knowing that packages do rebuild is not bad, and in actuality it's helpful to check for problems in libraries that may or may not be working, or check of a package can simply be rebuilt at all for sanity's sake. That's not something I grabbed from LFS so bury that notion please. Is it more sane to have packages that can be rebuilt and work, or packages that can only exist, after enough time, in binary only form? That's common sense Eric.

All distributions are a form at LFS at some point Eric. You can't just fold your arms and blink your eyes and magically have a distribution without a starting point, even if it started over two decades ago. Slackware at one point was from source from Softlanding, so was Red Hat, Debian, Arch, and others respectfully to their own. If Slackware is the chicken, then Softlanding was the egg, but before it came the source which was the chicken. Didn't you have to build a cross compiler for ARM and then work together a system to bootstrap things?

Audit can mean anything from any number of types of audits. Take your pick. Audit to me means: does everything work, does everything rebuild cleanly, are patches needed, and are all dependency issues resolved. If audit means having sanity in build, package, dependencies, and such to having a fully working system, and that's wrong, well I'll be wrong then, and proud to be wrong and rightfully.

Besides there are several packages I did have to rebuild due to libraries from dependencies being incorrect. I'm not saying each release cycle should have each package rebuilt, but from time to time packages should and could be tested for problems, and have them noted for sanity's sake.

You are completely missing the point. You are not talking from a Slackware policy & philosophy point of view but from a LFS pov.
Every distro starts at some point, indeed, but Slackware was not started from scratch. It developed further on the pre-existing SLS and was never rebuilt from the ground up, except for SlackwareARM and Slackware64 which were created from scratch. Creating Slackware64 resulted in many SlackBuild cleanups because the second goal of creating a port for x86_64 was to end up with a single unified source tree from which all the $ARCH versions could be built.

But Slackware is not a "from scratch" distro even despite the above explanation. Slackware packages are not rebuilt unless a change in another package or a security bug warrants a rebuild. This sets Slackware apart from the other (younger) distros who at some point will rebuild every package - but never from scratch! Rebuilds are always done on an existing OS installation.

That's your definition which is OK, but then it bears no relevance to Slackware.
I do not dismiss, underestimate or underappreciate the work done by people who build Slackware from scratch - it is a fun experiment, you will learn a lot from Slackware internals, compilers and source code patching, but that is all it is. Not relevant to Slackware.

2 members found this post helpful.

I didn't, but there are many things which didn't build just because it was ARM, let alone which wouldn't build on x86 at the time I was working through them.
It was not a problem for me and isn't one going forwards. I upgrade to the latest version (unless it's going to be far too different from what's in x86) or applied patches to the ARM tree. In some cases Pat upgraded to the latest versions because I asked, or it happened later as part of the natural evolution.

As Eric says, Slackware is not a gentoo - as a contributor to Slackware I am not too interested in whether something in the tree no longer builds - even on ARM - unless I specifically want to or need to rebuild it then I look for the solution.
I like the *idea* that everything should be able to built at any moment in time, but it's not important when there's one person who builds and distributes the OS. There are far more important things to do with one's time.

And I even said it was an egg from the SLS chicken. SLS came from source. You're even contradicting yourself. Saying something isn't from source, but then saying it was built from the ground up as not from source, sorry, but that doesn't make any sense. From scratch means from source. It's a starting point, even if it results from the clean up of existing SlackBuilds.

I never said rebuild the entire OS as a whole. What I'm saying "Make sure every package can be rebuilt against the existing system cleanly. If it can't, find out why and fix it." You're saying LFS is from source, but how is LFS, by your own definition from source? Technically, if I follow your logic, my LFS system is a Slackware based build that has no real beginning. Auditing the system build tree, is not a bad idea. This makes sure that each package works, all dependencies are resolved, and that nothing is broken in the system.

Isn't learning about the system, doing things the right way, understanding how a system works, and keeping a system sane and sound part of the Slackware way and of the utmost relevance? However, saying something isn't relevant when someone puts in time and effort to make sure each package can be rebuilt correctly, concisely, and without issue, and if an issue is found, fix said issue by whatever means possible, is a bit on the side of dismissive.

I never said it was Gentoo. However at what point do we say that a package is no longer needed if it can't be rebuilt, and who uses it? Would it be a trivial matter if something critical like GCC stopped building and couldn't be built again due to a dependency never building, and then we find out that deep into the tree something as trivial is binutils was never rebuilt and required a rebuild to work?

I'm only saying, better safe than sorry, and double check the work before you commit. You don't just open a random bottle and pour it on a fire without first checking to make sure what's inside isn't flammable or explosive.

I think there was a period of maybe a couple of years where WindowMaker could not be built on recent Slackware, not because anything else was broken, but because WindowMaker was half-abandoned and didn't support being compiled against a modern toolchain. The binary package compiled several releases prior still worked and was still included in Slackware (yay glibc backwards-compatibility). There was no 'issue' to be resolved by the Slackware team -- the options were to drop WindowMaker or continue to ship the working package.

WindowMaker was picked up by other developers since then and is now compilable but it illustrates the whole point -- packages that do not compile are not considered 'broken' in Slackware. If a package upgrade is needed (or if a package really does need to be recompiled against newer dependencies because it was broken by a dependency upgrade, for example) then it will be recompiled and the SlackBuild modified as needed to do so, but if there is no newer version, or if newer versions are intentionally being avoided for whatever reason, then there is no need to make sure the existing package can be rebuilt as long as the existing package still works; doing so would be nothing more than a practice exercise and that work wouldn't actually be used. With Slackware's small team size, doing work that is merely educational with no practical value just takes up time that would be better spent elsewhere.

There are plenty of distros that *do* try to ensure that every package can be built; Slackware isn't one of them. If you want this, go elsewhere or do it yourself; I doubt Pat wants to bother patching SlackBuilds unless he actually needs to. (This is not to say that community efforts to provide this capability wouldn't be valuable -- a git repo that tracks Slackware's sources with patches to fix compilability issues where needed may be useful for the community. But this has nothing to do with Slackware's development.)

There is distinction. Obviously it's from source, but 'from scratch' to me means that there's nothing already in place from which you can bootstrap. A Slackware specific example is the old 'tcpip' package from the 'n' series built from source -- everything compiled -- but only if you already had the tcpip package installed, since it was self referencing.
This is a different problem from some code no longer building because it no longer meets the standards gcc dictates, or something of that nature.


The metaphor doesn't work for me. Nobody comes to physical harm because some software failed to compile; and you'd never even know if something still worked or not without pouring it on the fire first.

The metaphor isn't meant to target anything. All it is hinting at is "Be sure you're right on all accounts, then go ahead with it", which is a common sense narrative to double check all work before you finalize things so the chance of problems is lowered or negated if at all possible.

change title

You need to change the title of the the thread in the initial post. For that, edit the initial post, click Save Changes, click Edit again, then click Go Advanced and change the title below Reason for Editing. Yes, that {c,sh}ould be simpler

sorry, there's no "edit" box available on the first post, only the last?

Probably because the first post is too old (although less than one month be not very old IMHO). Then press Report on your first post and request a moderator to change the title for you.

Slackware has it's point of view, others have theirs.
a package that can not be reproduce is in some parts of the industry a no go, and I agree.
there are good reasons why software should be re producible without going back, update , ... https://wiki.debian.org/ReproducibleBuilds
even debian tries to provide bootstrap information for the whole system, https://wiki.debian.org/DebianBootstrap (even if I do not know how useful this is)

I didn't thought trying to build slackware from sources would create so much animosity beyond members.
My goal was just a personal challenge, and if possible share my experience.
By doing it, I just wanted to help.
By finding packages that didn't build anymore, I only suggest a solution when possible, I don't require anything.
The purpose of this thread was not to talk about politics, religion, philosophy, or the way slackware should be done.
Just consider it as an educational exercise.
Just consider it as a toolbox.
No need to talk about hidden message in it, LFS was just a tool, nothing else.
It doesn't aim at proving anything, except it was feasible.
Those able to decide are smart enough to consider it valuable or not.
The others can use it or not.
Finally I don't care.

14 members found this post helpful.

Don't worry about it :-) your splendid work didn't create any animosity. I've seen those users butt heads over this subject several times in the past.

What you've done is very useful. From my perspective it adds an additional element of assurance to this great distribution that, whatever may come, we will find a way forward.

2 members found this post helpful.

It's all a matter of opinion. By now you should know what the point of view is of the Slackware Linux distribution, it has never been different and will stay its course.