Would anyone use a slackbuild tree to bootstrap their system? How many people would actually use it? The slackbuilds would of course, have some fixes-edits to compile succesfully with optional multilib slackbuilds. It'd only be tested on a 64-bit multi-lib rig without KDE too (though kdelibs builds fine). Some packages would be left out too (ccache, libkarma, jadetex, and maybe a couple others).

Thoughts?

Regards

Kinda all depends. Unless you're building for a new architecture, it's kind of pointless.

Slackware has some trouble compiling against itself from what others have mentioned, and the last known attempt worked but required some patchwork to be successful, but mostly for the base system (/a and maybe /ap) I think.

The Slackware system was designed to be continually updated against itself, but not rebuilt against itself, from what I've gathered. This made it easier to maintain in the long run with the -Current and *64-Current trees.

I think the only distributions that are known to possibly rebuild against themselves are LFS and Gentoo.

Don't get me wrong. I'm not discouraging you from trying, but it will be some level of work you might not be ready for.

What is the goal of it ?

If you want a bit of extra performance you can just recompile the kernel, glibc, glib, glib2. That speeds it up plenty.

Well, I for one think it would be a great learning endeavour. If you decide to do so, please keep us posted. I would be interested.

Do be careful how you rebuild it. Most stuff is compiled at the GCC recommended mtune flags -O2 and -fPIC or -i486 depending on the architecture involved.

I've really never seen anyone build using an mtune native flag or -O3 successfully, or run stably.

This isn't generally considered to be technically feasible. In fact, I've never heard of anyone making it work. If you can, though, then I know the number is more than zero.

Some of us (myself included) like to rebuild the odd package with different options to add - or strip - some extra functionality, so it's nice to have the source code and the build scripts around. I'm currently writing a long article on package management for the Slackware Documentation Project. It's not yet finished, but the section about rebuilding official packages is already online. Check it out here:

http://docs.slackware.com/slackware:...ement_hands_on

Cheers,

Niki

3 members found this post helpful.

It'd be odd releasing a tree that compiles against itself, considering many slackware users prefer to be simple (slackware is meant to be simple) without things like bootstrapping the entire installation. Things are more complicated with bootstrapping and think maybe Patrick might benefit more from it but who knows; maybe unless you get some scripts that do most of the work for you (I have my own). The tree is pretty much stock slackware, except "-O2 -fPIC" is $CFLAGS, multilib slackbuilds are there, has fixes so things actually build, and it doesn't mangle the original slackbuild-tree.

Would probably diff or something against the original slackbuilds and release that. Don't want to release my scripts since they really are basic, but I could include examples of how to do stuff (think it's a lot more cool to let people do it their way). Might have to write a curses program (like sbopkg), but that's really beyond my scope right now. Don't think many would like running bare scripts only (I personally prefer a curses based program)...

EDIT:
I'm personally shocked Slackware is stable as it is considering it's never cleanly built against itself; correct me if I'm wrong. Things are supposed to have integrity and be consistent. When you do things in the *NIX world, you do them well http://www.howtogeek.com/182649/htg-...-what-is-unix/.

Regards

On this topic, see this thread There are others, that I am not able to find at the moment.

3 members found this post helpful.

Slackware is a lot of fun and yes building bootstrap could be a fun thing to. But I will say this if it aint broke why fix it has been around. Such as libmad has not been rebuilt since 13.37 you will find you need to edit it so it will build on the 4.7.1 and the 4.8.2. I needed to rebuild it static for an embedded program I was working on. there are more hurtles to jump then just bootstrap.

I guess it would be very educational. However, I like how Slackware installation goes blazingly fast on a modern hardware

It's certainly possible to build everything from scratch, and (except for a few specific packages that break due to toolchain updates) quite easy in fact, and Slackware gives you all the tools to do it.

But!

Consider what's different between an Official Slackware package, and a package I've built myself.

The Official Slackware package has been tested and used by tens of thousands of people, maybe even hundreds of thousands. Whatever toolchain was used at the time it was built, apparently it worked fine. Even if Patrick's build host suffered a random single bit memory error due to a passing cosmic ray, apparently it didn't break anything in the package, otherwise someone would have reported it.

My package hasn't had that kind of hammering. Even if it seems to work ok, it's on probation.

3 members found this post helpful.

I don't know if we are talking about the same thing here but on my gentoo I use march native and it builds fine

I would care to rebuild slackware form sources. Actually, I don't care it, but rebuilding from source is the only way to get "proper binaries" for me. "Proper binaries" for me is such binaries which was generated from sources using -g option(for gcc, or corresponding for other compilers), and was not processed with "strip", e.g. binaries which contain/provide full debug info. If I could get debug info from others sources, I would be ok with binaries provide out-of-box of slackware.

Might be interesting to try. A long time ago (in a galaxy far, far away) I installed Unix from 9-track tape on a PDP-something (don't remember the model); "installed" means "build everything from source," lots of Makefiles. You read the instructions, get all the hardware specs, loaded up a platform compatible C compiler (maybe an assembler -- there was some minimum amount of assembly code -- and loader and a couple of other rudimentary tools while you're at it), mount the tape, type make and wait awhile. Well, a long while actually -- tape drive spinning, stopping, starting, backing up, messages printing on the console (yeah, console used to be a hard-copy terminal, anything from an ASR-33 up). Every so often maybe type something or other. Bell Labs did a really nice job of making it happen in one go with one make (one assumes that Dennis Ritchie had a lot to do with that). Some hours later I had a bootable file, unix, a way to make it boot and a bunch of utilities to do actual work with. You edited with ed (later ex still later with vi, which is just ex in visual mode thanks to Bill Joy and crew).

So, following that "work your way down the tree kind of rule," figure out what order to build and install what with, edit up a bunch of Makefiles with one to control all of them and viola! SlackBuilds are, pretty much, just configure - make - make install, after all.

Pat's gotta do it somehow, maybe he'll tell you the sequence (or maybe it's in the documents somewhere)?

I do think it would be an interesting and probably frustrating exercise, but like Kiki Novak I do rebuild one or two base system packages every so often to add or eliminate an option (I do that with PHP to add a DBMS that's not one of the defaults). That's not difficult but I suspect that the entire system would be a challenge.

Hope this helps some.

1 members found this post helpful.