Every rebuild of a package has a possibility of introducing new bugs due to changed build environment.

From an academic standpoint it's attractive to have a system, which completely builds from source. So your can port your distribution to a dozen of platforms. But you don't know if all the resulting binaries still work as intended. And you have no way for automatically testing this.

I saw this problem in the BSD ports tree: They make sure that all the stuff compiles fine (and mark it broken if not), but checking if the created binaries are still usable is up to the user who builds them. It is also common practice to rebuild a lot of packages when ABI changes, which usually happens by major upgrades of the base sytem.

On Slackware you have the option to keep good working packages around even between major dist upgrades. That is another advantage of having no dependency trees, which degenerate fast in such scenarios.

2 members found this post helpful.

There's a single french guy who sort of did what is described here. His distribution "0" (as in "zero") is a curious mix of Slackware and LFS. He's apparently a full-time admin/geek paid by a scientific lab. He also translated everything (script comments etc.) from english to french.

http://0.tuxfamily.org/doku.php

As for Slackware... I did LFS once, only to find out that it's the perfect distro for folks who build cathedrals out of matchsticks or cram sailboats into bottles for relaxing. My current approach is more "Linux From Slack", where I install a more or less vanilla base system, and then I either build my own extra packages, or I grab stuff directly from SlackBuilds.org. Same approach on servers and desktops.

1 members found this post helpful.

When it comes to a particular source package not compiling because of a tool-chain change, this is either an upstream source problem, or possibly a buggy tool-chain. So if you want to try to build, and something no longer works, then please report this stuff upstream. My opinion is that when issues arise from this, this is not a slackware problem, unless the tool-chain in the current form is unstable or incorrect (which is rare because they clearly test the stuff before moving the tool-chain to current). So any project to test the sources regularly is more like LFS in nature, and outside of the main slackware project.

It's good there are people out there that want to keep track of this because it will benefit every one. If upstream corrects a problem, slackware will get it eventually.

I have found that the slackbuilds are quite portable to completely different tool-chains (older and newer, and even in other distros). The problems I have usually are not what with was done, but satisfying the dependencies in the same build order.

Just to make things clear, is this a fork that you're planning or your own private stuff?

The problem with porting hadn't crossed my mind until chemfire even mentioned it. This could be one of the few idealized instances where an audit might be required.

From auditing a code freeze for a system port you could identify problems with code and compiling for a new architecture and show where at minimum the core can be stabilized through patching and then everything else slowly rebuilt around it, if initial compiling doesn't work right away.

As far as actual development goes, it might not be worth the effort as Eric mentioned unless the staff could agree on it, volunteers would help, and the payout be justified.

Though one thing I could say, a full core and core-dev rebuild would only be as necessary as the GNU C Compiler Suite gets updated to ensure compile compatibility, which luckily isn't often. I would dare to guess GLIBC is updated more often. Afterwards it's just security patch, minor upgrades and updates, and all, but at least it's confirmed everything for the core could be rebuilt on a moment's notice, even using a master build script just for the core and core development packages of the system and nothing else.

An audit team might not be a bad idea.

When it's ready it will be released as a Slackware port. The main difference with ARMedslack (apart from targeting newer CPU generations with hardware FPU) is the fact that I Have an additional goal and that is to keep the complete source tree compatible with Slackware's official source tree. You may have noticed that Slackware has steadily been moving toward unifying the source directories of the 32-bit and 64-bit release trees. Ultimately I want that source tree to be able to support an ARM architecture as well.

I will also release my scripts to build the cross-compiler and mini rootfs containing the native toolchain. The scripts are created in such a way that adding another architecture should be fairly trivial. What I have based my scripts on is http://fedorapeople.org/cgit/djdelor.../bootstrap.git

Some traces of my work are visible throughout the Slackware source tree if you watch closely.

Eric

Eric,

Did you (and others?) do a complete rebuild of all Slackware packages when you put the first Slackware64 release together?

Regards,

I "THINK" most of what was done for Slackware64 was an import of Slamd64 back into the main tree with the multilib stripped back out in favor of a non-multilib package for the compiler suite. However, to get your questions fully answered you'd really have to ask the creator of Slamd64, Fred Emmott.

I would however, assume that everything did, at least on a temporary basis, have to be initially built from scratch for the 64-bit platform from a frozen source base to get a working base system created and then started back into the normal package release cycles.

I don't think that is true. If you search around for old comments from Alien Bob on this forum, you find stuff like this:

Yes, I built Slackware64 from the ground up, that caused a lot of package updates and patched to added to -current at the time - because lots of the "old" packages which had not been rebuilt in Slackware for years, would not compile without additional patches or even version bumps.

I am experiemcing the same now that I do this ARM port.

I did not use anything from Slamd64 except inspecting configure flags when I was at a dead end (but I used the LFS documentation a lot more than looking at Slamd64 scripts). You must be confusing my work with the Bluewhite64 port which essentially cloned Slamd64, removed multilib and re-branded it.

The most important goal I had at the time was cleanup the existing Slackware package scripts. A lot of them were stone-age and not at all formated like the "modern" SlackBuild scripts we all know now. Heck, several package scripts were not even SlackBuild scripts! I did this because Pat was not at ease with my plans for the port and feared that having to maintain it would at least double his efforts. The advantage of my work was that there is now one unified source tree from which the two (x86 and x86_64) architeccture releases can be built. That still requires compiling twice as much packages as in the old days, but compiling is not such a large part of the total development time.

The package build scripts of most of the Slackware ports (ARMedslack, Slamd64) but also forks/derivatives are usually too different from Slackware's originals that adopting those would certainly double the maintenance effort for Slackware. I did not even consider for a moment using one of these ports for any of my own work.

Eric

Interesting! Just the other day I was looking at some of the armedslack-13.37 Slackbuild scripts and comparing them with their slackware-13.37 counterparts and realised it was completely different (e.g. aaa_base.SlackBuild [armedslack-13.37] and aaa_base.SlackBuild [slackware-13.37]). I agree, your way of having a single SlackBuild be able to make all architectures would be a lot easier from a maintenance perspective.

@Alien Bob: As a side note, do you know (or perhaps, can you comment on) if Stuart is planning to bring his SlackBuild scripts in line with Slackware, Slackware64 and your future ARM-based port? I notice that for 14.0 he is now using the name "slackwarearm" on the mirrors, rather than "armedslack" but he is still using his own build scripts.

He is not going to change his scripts.

Eric

@AlienBob:
So , just for the sake of clarity of the present discussion, I understand that actually it has been done, I mean, a complete compilation right from "the ground".
Would it be worth to share the "general" steps of that "just-one-occasion" recompilation of Slackware?

I have been interested on using a minimalistic version of Slackware for a (micro?)-HPC cluster, and have been reading about some of the different experiences on that matter here at LQ, but then that raised more questions about the possibility of just starting from zero, and then building Slackware just like you did. (Of course, in reality this is not practical or necessary for creating a minimalistic version, but just for "academic" curiosity).

Cheers,

I am actually a bit disappointed. I actually rooted for a complete fork of the ARM tree. Why? Because Slackware was born for the PC. ARM devices are different beasts. If you plan for an unified source tree you either sacrifice the PC port or the ARM port.

1 members found this post helpful.