LinuxQuestions.org
Visit the LQ Articles and Editorials section
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices

Reply
 
Search this Thread
Old 09-04-2012, 09:14 AM   #16
jtsn
Member
 
Registered: Sep 2011
Location: Europe
Distribution: Slackware
Posts: 800

Rep: Reputation: 354Reputation: 354Reputation: 354Reputation: 354

Quote:
Originally Posted by ReaperX7 View Post
I understand Eric and yes it would be a massive undertaking but the question other than evolution of existing packages and basic binary compatibility, could Slackware at the core of the system hypothetically ever be frozen in code and completely rebuilt as an audit of the existing code?
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.
Old 09-04-2012, 11:00 AM   #17
kikinovak
Senior Member
 
Registered: Jun 2011
Location: Montpezat (South France)
Distribution: Slackware, Slackware64
Posts: 1,489

Rep: Reputation: 662Reputation: 662Reputation: 662Reputation: 662Reputation: 662Reputation: 662
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.
 
Old 09-04-2012, 01:42 PM   #18
the3dfxdude
Member
 
Registered: May 2007
Posts: 315

Rep: Reputation: 84
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.
 
Old 09-04-2012, 02:11 PM   #19
ottavio
Member
 
Registered: Nov 2007
Posts: 312

Rep: Reputation: 46
Quote:
Originally Posted by Alien Bob View Post
I am doing exactly that as an exercise. I am creating a new ARM port which re-uses nothing at all from the ARMedslack distribution.
Just to make things clear, is this a fork that you're planning or your own private stuff?
 
Old 09-04-2012, 02:54 PM   #20
ReaperX7
Senior Member
 
Registered: Jul 2011
Distribution: LFS-SVN, Slackware-14.1, PCBSD-10.0
Posts: 2,798
Blog Entries: 15

Original Poster
Rep: Reputation: 731Reputation: 731Reputation: 731Reputation: 731Reputation: 731Reputation: 731Reputation: 731
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.

Last edited by ReaperX7; 09-04-2012 at 02:59 PM.
 
Old 09-04-2012, 02:59 PM   #21
Alien Bob
Slackware Contributor
 
Registered: Sep 2005
Location: Eindhoven, The Netherlands
Distribution: Slackware
Posts: 5,184

Rep: Reputation: Disabled
Quote:
Originally Posted by ottavio View Post
Just to make things clear, is this a fork that you're planning or your own private stuff?
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
 
Old 09-04-2012, 10:35 PM   #22
Lufbery
Senior Member
 
Registered: Aug 2006
Location: Harrisburg, PA
Distribution: Slackware 64 14.0
Posts: 1,142
Blog Entries: 29

Rep: Reputation: 119Reputation: 119
Eric,

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

Regards,
 
Old 09-04-2012, 11:23 PM   #23
ReaperX7
Senior Member
 
Registered: Jul 2011
Distribution: LFS-SVN, Slackware-14.1, PCBSD-10.0
Posts: 2,798
Blog Entries: 15

Original Poster
Rep: Reputation: 731Reputation: 731Reputation: 731Reputation: 731Reputation: 731Reputation: 731Reputation: 731
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.
 
Old 09-05-2012, 01:08 AM   #24
ruario
Senior Member
 
Registered: Jan 2011
Location: Oslo, Norway
Distribution: Slackware
Posts: 1,795

Rep: Reputation: 803Reputation: 803Reputation: 803Reputation: 803Reputation: 803Reputation: 803Reputation: 803
Quote:
Originally Posted by ReaperX7 View Post
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.
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:

Quote:
Originally Posted by Alien Bob View Post
Slackware64 is a clean-room build from scratch with 32bit Slackware as the foundation
 
Old 09-05-2012, 01:52 AM   #25
Alien Bob
Slackware Contributor
 
Registered: Sep 2005
Location: Eindhoven, The Netherlands
Distribution: Slackware
Posts: 5,184

Rep: Reputation: Disabled
Quote:
Originally Posted by Lufbery View Post
Eric,

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

Regards,
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.

Quote:
Originally Posted by ReaperX7 View Post
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 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
 
Old 09-05-2012, 02:45 AM   #26
ruario
Senior Member
 
Registered: Jan 2011
Location: Oslo, Norway
Distribution: Slackware
Posts: 1,795

Rep: Reputation: 803Reputation: 803Reputation: 803Reputation: 803Reputation: 803Reputation: 803Reputation: 803
Quote:
Originally Posted by Alien Bob View Post
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.
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.
 
Old 09-05-2012, 02:50 AM   #27
ruario
Senior Member
 
Registered: Jan 2011
Location: Oslo, Norway
Distribution: Slackware
Posts: 1,795

Rep: Reputation: 803Reputation: 803Reputation: 803Reputation: 803Reputation: 803Reputation: 803Reputation: 803
@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.
 
Old 09-05-2012, 04:51 AM   #28
Alien Bob
Slackware Contributor
 
Registered: Sep 2005
Location: Eindhoven, The Netherlands
Distribution: Slackware
Posts: 5,184

Rep: Reputation: Disabled
Quote:
Originally Posted by ruario View Post
@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
 
Old 09-05-2012, 10:31 AM   #29
caduqued
Member
 
Registered: Apr 2008
Location: Coventry, United Kingdom
Distribution: Slackware64, Slackware64 13.37, linuxslackware
Posts: 81

Rep: Reputation: 19
Quote:
Originally Posted by Alien Bob View Post
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 experiencing the same now that I do this ARM port.

...

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,
 
Old 09-05-2012, 11:18 AM   #30
ottavio
Member
 
Registered: Nov 2007
Posts: 312

Rep: Reputation: 46
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.
  


Reply

Tags
init, slackware from scratch


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Installing Slackware from scratch. glore2002 Slackware 16 09-03-2008 06:44 AM
Installing Slackware 10.2 from scratch dfresh Slackware - Installation 9 11-10-2005 01:44 PM
Slackware from Scratch? dhave Slackware 10 02-07-2005 04:04 PM
ali aladdin v agp stinks :scratch: :scratch: :scratch: Mr Marmmalade Linux - Hardware 1 07-08-2003 05:11 AM


All times are GMT -5. The time now is 06:37 PM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration