Rebuiding the latest Slackware Linux release from it's sources. It's is posible?
 

Imagine that I'm an stupid and idiot Slackware(32) user, I use a Phenom II x6 as main system and secondary I have a little 8 x Phenom x4 (with all bells, ie 2GB RAM, 2x640GB RAID0, per system) cluster. I have the processing power to re-render the entire Avatar in a reasonable time, BUT!

I want to rebuild the entire Slackware Linux, at current/latest version, from a slighty different target: i586 or i686.

My question is: The Slackware Linux sources is published at latest version? I can rebuild the entire operating system from sources without other patches or upgrades/downgrades from the official packages versions?

Not quite. Slackware packages tend to get updated piece by piece. It's not unusual to find a few of the Slackbuilds won't compile under the current release and the binaries you are running were actually inherited from a previous release. Usually all it takes is the odd patch or version bump to fix though.

Also, there are the odd few packages, such as the kernel-headers that don't have a slackbuild script.

To understand that the current Slackware Linux is NOT able to succeed the old good thing "it's able to rebuild itself"? We can't rebuild the current Slackware Linux from it's sources?

Everything you need to compile is found either within the source directory of the distribution or the patches/source directory. However, there is no indicator of the order in which the packages should be built and installed, as far as I know.

If you have that much horsepower, then I guess that you'll use distcc when you build stuff. You may want to look at https://launchpad.net/slackbot to get some ideas.

Nope. It's quite possible that Slackware current, or even a Release isn't capable of completely rebuilding itself.

Consider this:

A library + headers get updated in current but the library is binary compatible with prior releases so existing packages that make use of it don't need to be rebuilt. But if that library/headers are not source compatible with the previous version then you end up in this situation.

It's also not unusual to see software that won't compile on a newer gcc without change though surely if the upstream projects write standards compliant code, that sort of thing shouldn't happen.

It's just a side effect of the chosen development model.

I say you consider using slackware64, because that will give way more performance benefit than going from i486 to i586 or i686, not to mention that slackware is actually mtune for i686, which makes the benefit even less.

In photography, it's common to find that the people with the most expensive and sophisticated cameras are unable to take really good photographs. The most famous photographers will all tell you that the equipment is not as important as the talent and experience.

Similarly, in computing, sometimes the most powerful and expensive systems are correlated with a "stupid and idiot" owner. In fact, many of us use it as a heuristic.

The best advice for someone who is "stupid and idiot" is: do not attempt "to rebuild the entire Slackware Linux" until you are not "stupid and idiot". This advice is independent of the speed of the user's Turing machine.

Other people have answered "No" to your other question. The reason is, to avoid pointless work. The aim of Slackware is to provide a prebuilt set of binaries that reliably work together, not 'the old good thing "it's able to rebuild itself"'. (If that's what you want, see LFS, and follow the LFS mailing lists if you want to know how difficult it is.)

And additionally, the reason for dropping Gnome was... :cool:

For context, this is actually a spin-off of this discussion:
http://www.linuxquestions.org/questi...221/page5.html

Well, I think different... I said about Avatar. It's something like J.Cameron was shocked in a dream by a idea and few (hundred?) admins was able to transform his idea in a movie.

However, in our case... we talk about an (Linux) operating system. IF Slackware Linux is not able to rebuild itself, it's bad, very bad. Because that seem that Slackware is not really OpenSource and can be sued for Infringement of GPL.

It's something like Microsoft Corporation try to present the sources of Windows 97 SE as the sources of Windows Seven.

I think, in this case, if Slackware can't be rebuild from sources, can be considered at the same level of closed-source Microsoft Corporation solutions, using (barely) open-source software.

It's very important to preserve the "it's able to rebuild itself" in a open-source operating system. It's the guaranty of a true GPL operating system.

BTW. I'm Slackware user starting with version 2.0, the "stupid and idiot" was an expression.

I don't believe that you know what you are talking about.

[edited for accuracy]

That's crazy talk.

An open source system with the capability to rebuild itself is certainly nice, but it not any sort of requirement or measure of it being open source.



I do wonder though why in the original thread no answer was given about what tools or scripts the slackware team uses to build slackware. There may be no requirement to release that info or tools, but it would seem to be the right thing "in the spirit"....

I think you misunderstand what is meant by open source in this regard. I means that the code is public, and developers are free to modify it how they wish. There are no guarantees about compilation. If there were guarantees about compilation, half of the programs I try wouldn't be close to being called open source.

In reading your posts on the thread that dugan linked to, it seems to me that what you want is the build order for the Slackware packages. I believe Eric aka AlienBOB has already answered that question, which is that they don't release it. That doesn't mean you won't be able to recompile Slackware from source. It just means that it will be extremely difficult.

Not really. An common method used by false OSS companies/solutions is to present sources with no value for the current release.

In fact, is commonly used also by some Linux distributions to "protect" their IP.

In fact, we have Closed Source, Open Source AND False Open Source.

Slackware same level of closed source Miscro$oft, using (barely) open-source software. How could u?? how could u??:cry:

Sorry, but that's the truth. :(

That method is named as "False Open-Source", i.e. imagine that the KDE-3.5.10 sources is presented as KDE-4.4.3 sources. Is common used today, and seems like that one of the "rats" it's called Slackware.