LinuxQuestions.org
Review your favorite Linux distribution.
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 06-27-2015, 12:11 PM   #16
ReaperX7
LQ Guru
 
Registered: Jul 2011
Location: California
Distribution: Slackware64-Current
Posts: 6,444
Blog Entries: 15

Rep: Reputation: 2013Reputation: 2013Reputation: 2013Reputation: 2013Reputation: 2013Reputation: 2013Reputation: 2013Reputation: 2013Reputation: 2013Reputation: 2013Reputation: 2013

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.

Last edited by ReaperX7; 06-27-2015 at 12:20 PM.
 
Old 06-27-2015, 12:24 PM   #17
Alien Bob
Slackware Contributor
 
Registered: Sep 2005
Location: Eindhoven, The Netherlands
Distribution: Slackware
Posts: 7,285

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

Quote:
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.
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.
Old 06-27-2015, 05:18 PM   #18
drmozes
Slackware Contributor
 
Registered: Apr 2008
Location: Surrey, England
Distribution: Slackware
Posts: 717

Rep: Reputation: 554Reputation: 554Reputation: 554Reputation: 554Reputation: 554Reputation: 554
Quote:
Originally Posted by ReaperX7 View Post
Didn't you have to build a cross compiler for ARM and then work together a system to bootstrap things?
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.

Last edited by drmozes; 06-27-2015 at 05:21 PM.
 
Old 06-27-2015, 09:46 PM   #19
ReaperX7
LQ Guru
 
Registered: Jul 2011
Location: California
Distribution: Slackware64-Current
Posts: 6,444
Blog Entries: 15

Rep: Reputation: 2013Reputation: 2013Reputation: 2013Reputation: 2013Reputation: 2013Reputation: 2013Reputation: 2013Reputation: 2013Reputation: 2013Reputation: 2013Reputation: 2013
Quote:
Originally Posted by Alien Bob View Post
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.
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.

Quote:
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.
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.

Quote:
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.
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.

Quote:
Originally Posted by drmozes
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.
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.

Last edited by ReaperX7; 06-27-2015 at 09:48 PM.
 
Old 06-27-2015, 10:42 PM   #20
T3slider
Senior Member
 
Registered: Jul 2007
Distribution: Slackware64-14.1
Posts: 2,367

Rep: Reputation: 838Reputation: 838Reputation: 838Reputation: 838Reputation: 838Reputation: 838Reputation: 838
Quote:
Originally Posted by ReaperX7 View Post
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 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.)
 
Old 06-28-2015, 12:46 AM   #21
drmozes
Slackware Contributor
 
Registered: Apr 2008
Location: Surrey, England
Distribution: Slackware
Posts: 717

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

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

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.

Last edited by drmozes; 06-28-2015 at 01:15 AM.
 
Old 06-28-2015, 02:49 AM   #22
ReaperX7
LQ Guru
 
Registered: Jul 2011
Location: California
Distribution: Slackware64-Current
Posts: 6,444
Blog Entries: 15

Rep: Reputation: 2013Reputation: 2013Reputation: 2013Reputation: 2013Reputation: 2013Reputation: 2013Reputation: 2013Reputation: 2013Reputation: 2013Reputation: 2013Reputation: 2013
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.
 
Old 06-28-2015, 03:12 AM   #23
nobodino
Member
 
Registered: Jul 2010
Location: in France
Distribution: slackware, slackware from scratch, LFS, linux Mint, Niresh (MacOS)...
Posts: 472

Original Poster
Rep: Reputation: 307Reputation: 307Reputation: 307Reputation: 307
Building from scratch

change title

Last edited by nobodino; 06-28-2015 at 03:15 AM. Reason: change title
 
Old 06-28-2015, 03:52 AM   #24
Didier Spaier
LQ Addict
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slint64-14.2.1 on Lenovo Thinkpad W520
Posts: 8,585

Rep: Reputation: Disabled
Quote:
Originally Posted by nobodino View Post
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

Last edited by Didier Spaier; 06-28-2015 at 03:57 AM.
 
Old 06-28-2015, 05:29 AM   #25
nobodino
Member
 
Registered: Jul 2010
Location: in France
Distribution: slackware, slackware from scratch, LFS, linux Mint, Niresh (MacOS)...
Posts: 472

Original Poster
Rep: Reputation: 307Reputation: 307Reputation: 307Reputation: 307
sorry, there's no "edit" box available on the first post, only the last?
 
Old 06-28-2015, 05:33 AM   #26
Didier Spaier
LQ Addict
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slint64-14.2.1 on Lenovo Thinkpad W520
Posts: 8,585

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

Last edited by Didier Spaier; 06-28-2015 at 12:03 PM. Reason: Typo fix
 
Old 06-28-2015, 06:06 AM   #27
a4z
Senior Member
 
Registered: Feb 2009
Posts: 1,727

Rep: Reputation: 739Reputation: 739Reputation: 739Reputation: 739Reputation: 739Reputation: 739Reputation: 739
Quote:
Originally Posted by Alien Bob View Post
You still look at Slackware as a different kind of LFS. No package needs fixes - they all work. Slackware packages are not recompiled randomly: only when needed. And the mere fact that the current source does not compile any longer does not make it mandatory to recompile the package which works OK.

Do you actually know what a code audit means?
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)
 
Old 06-28-2015, 06:09 AM   #28
nobodino
Member
 
Registered: Jul 2010
Location: in France
Distribution: slackware, slackware from scratch, LFS, linux Mint, Niresh (MacOS)...
Posts: 472

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

Last edited by nobodino; 06-28-2015 at 04:36 PM. Reason: no need to expand.
 
14 members found this post helpful.
Old 06-28-2015, 11:48 AM   #29
ttk
Member
 
Registered: May 2012
Location: Sebastopol, CA
Distribution: Slackware64
Posts: 732
Blog Entries: 25

Rep: Reputation: 881Reputation: 881Reputation: 881Reputation: 881Reputation: 881Reputation: 881Reputation: 881
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.
Old 06-28-2015, 12:16 PM   #30
Alien Bob
Slackware Contributor
 
Registered: Sep 2005
Location: Eindhoven, The Netherlands
Distribution: Slackware
Posts: 7,285

Rep: Reputation: 5433Reputation: 5433Reputation: 5433Reputation: 5433Reputation: 5433Reputation: 5433Reputation: 5433Reputation: 5433Reputation: 5433Reputation: 5433Reputation: 5433
Quote:
Originally Posted by a4z View Post
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)
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.
 
  


Reply


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
[SOLVED] Building SQLite-3.8.8 on Slackware-14.1 rshepard Slackware 6 01-20-2015 07:12 PM
Building xbmc on Slackware 14 Woodsman Slackware 1 09-10-2012 11:10 PM
android building and Slackware {davros} Slackware 6 07-21-2011 02:46 AM
Cross-Building Slackware as a whole? gargamel Slackware - Installation 2 05-09-2004 07:31 PM
Building a Slackware PC Odin_of_Asgard Linux - Hardware 1 03-13-2004 12:01 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

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

Main Menu
Advertisement
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
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration