Not everything must be recompiled. We can maintain dependencies.

I'll let Pat speak for himself about what he seeks for his own image, but I'll share a short story.

A neighbor up the road from me runs a small wood shop for his livelihood. He lives a very humble life and is not interested in modern electronic technology. He has no TV in his house and he raised the children without a TV. Several years ago I asked him if he considered posting a web site to sell his products. He wanted nothing to do with the idea. He said he was satisfied with the volume of sales he had and did not want further exposure. His point was that he was content with his humble lifestyle and sought nothing more.

If Pat is interested in increasing market share I suspect he'll act upon those desires. If not then I suspect he is satisfied with his current lifestyle.

Contrary to the Canon camera commercials from several years ago, image is not everything. Word-of-mouth advertising continues to carry significant clout with many people. The point is that Slackers tend to find Slackware rather than vice-versa.

There are several areas where I think Slackware could improve. I have posted such ideas in this thread as well as other threads. I routinely forwarded ideas and bug reports to Pat and his support staff. Some ideas were adopted and some were not. Yet all of my discussions focused on usability issues, not image.

That is not to say that perhaps modifying the web site is immaterial. I think image comes in different forms. Pat's web site reflects the product --- functional without glitz. I don't own a suit or wear ties. I don't have problems with my image. A firm handshake, a smile, and keeping my word have done more for my image than outward appearances.

"Not everything must be recompiled. We can maintain dependencies." I know this well enough -I don't need any such script myself as I'm quite cpable of recompiling any or all of the OS I want. It was a tounge-in-cheek(notice the LOL) comment exactly because I am aware of the possibilities and difficulties of re-compiling and especially automating that process. Occasionally someone posts here with the idea of completely re-compiling slackware -usually with the goal of optimizing for i686 or other arch. The usual result is a flurry of posts over a couple of weeks, then reports of failing hardware (from all the flailing and gnashing) and then no more is heard.
Over the last couple of months I have been slowly building a system which runs on a loongsonf (mipsel) architecture, so I'm quite familiar with the procedures and the ups and downs of ones motivation for doing it at all.

Hello gnashley, some time ago I complained to Pat. upon serious bugs (hang-ups) of SCIM, which occasionally render X totally unusable. I suggested him to add SKIM to Slackware. He replied to say that he did say something to the team about SKIM but he did not receive any response, neither positive nor negative. He also said that the misbehaviour of SCIM is due to the team's forgetting to recompile SCIM after some updates. So you can see, human memory is not so reliable as makefiles.

Thanks to AlienBob it's already there but you just have to feed some info at the boot prompt.

You can give it a static ip too if you want basically:
Again it's mostly there but you just have to either edit the initrd yourself or be there to give the parameters... we can't do this as everyones needs are different.

I don't see anything funny here.
If you think idea is funny, then I suppose you are imagining something else, or looking at the problem from the wrong angle.
Reread information about Makefiles or any other system with dependency handling. Just make packages dependant on slackbuilds, make correct build order and you are half done (you still might need chroot, or virtual machine to test this thing).The thing is definitely possible to do, but right now I wouldn't do it "just for the sake of accomplishing it".

When something can be automated but instead is (re)done manually many times - this is called pointless waste of time.

You didn't understand the idea. I wanted the script that creates slackware installation dvd from source (or from nothing - given the interenet access). Or directory tree for slackware DVD. As simple as that.

And cross-compiling for another arch is different story, which isn't even close to what I wanted.

Anyway, if there is no build script, then this is my first huge disappointment with slackware which will negatively affect my opinion about distro.

I don't give a damn about flurry of posts or something, I'm not going start building it right now just to prove concept, etc. The thing is possible to implement and I am sure about it. If I ever become interested enough in implementing it - I will implement it.

As for people that "tried to do that and failed" - this doesn't really tell me anything useful. I have not seen their scripts, their build system, don't know their skill level, and so on.

Right now I am more interested in getting more contracts than spending few weeks to develop this script "just for fun" and then going through the trouble of submitting it somewhere where it will remain lost and forgotten after that. Been there, not interested anymore.

I seriously doubt that most people will appreciate that. Most likely reaction will be few responses "wow, that's cool, it works" and that is it. Very small number of people will ever use that script seriously, because only very small amount of people ever needed something like that. Solving this problem will not provide sufficient challenge (no "feeling of accomplishment"), it will take a lot of time and hardware resources, and will not pay back in any way. So right now I am not interested.

I will not discuss this problem further.

OpenOffice instead of, or in addition to, KOffice.

VLC (Videolan) as the default multimedia application.

How many times a year do you think Slackware is being recompiled from source? Exactly! Never! The only time a package gets recompiled is when it needs an update. I think you are mixing Slackware with a "build from source distro" like Gentoo or LFS. You are confusing the fact that it is easy to compile add-on software from source in Slackware, with Linux distributions that compile their entire base set from source.

I think you fail to see the real issue. The Slackware package tree can not be compiled as a linear process. There are many packages that have circular dependencies - package X can not be built before package Y, but package Y wants to find an installed package X because then additional functionality will be enabled. Compiling Slackware from scratch means building and rebuilding, adding more finalized packages with each (partial) rebuild. The package creation logs have to be inspected to find out what packages need a recompile at a later stage when other packages have become available. I think perhaps Gentoo tries to make this process automated but fails nevertheless (look at the discussions in their mailing lists).

And why would that be a huge disappointment? There is no need for this script to be part of Slackware. Slackware is what it is because of the careful attention the packages get. I can only think of one reason why you show such an attitude...:

And here I find that reason. You want to make money out of it by rebuilding Slackware (to use for your our potential customers?). You do not want to write such a script yourself, but demand that the Slackware developer makes it available instead?

I hope I have it all wrong. If I am, feel free to flame me.

Eric

Please consider dependencies.

Please clarify your question.
You mean that Slackware should check dependencies? In that case you'll be disappointed - Slackware will never add dependency checking to the package format.

Eric

This is what makes slackware unique and is probably one of the prime reasons for Slackware's long standing popularity. Thanks for wowing not to disappoint the majority of devoted Slackware users!

Hello, Pighead. All the way long YOU and us are talking about "How to BUILD Slackware Automatically". So I must have meant the "BUILD DEPENDENCIES", which has nothing to do with installpkg. Do you really not understand?

I do not see a reason for name calling. You write a single line which is multi-interpretable. I only ask for more detail, and that is no reason to start pissing on me.
You disappoint me.

And still I have no idea what you intended to say. Build dependencies? If you want to take care of build dependencies automatically during a from-scratch compilation of Slackware, that is in fact only possible when you have a package manager that does dependency resolving. Why is this pigheaded?

Eric

Interesting...I'll have to give the SlackBuilds a try. Thanks, Alien! Any possibility some of those would end up in Slackware (or at least on SBo? I know some corresponding SBs are already there).

have you submitted your colorized boot scripts patches? I think having something similar in Slackware (perhaps with a colored echo "echoc" command), but turned off by default, would be a pleasing addition to Slackware.

Which means if precompiled packages are lost due to the server failure, rebuilding everything back will take a lot of time.

How I see it:

• Prepare list of source package.
• Prepare minimal toolchain, that cannot be built automatically (probably glibc/gcc).
• Make empty system with only that toolchain.
• On that system. For each entry in the list of packages:
  • attempt to build package using slackbuild.
  • if configure or make fails (exit with error code), push it to the end of list and mark that it has failed to build at least once.
  • if compilation was successfull, put package into the repository AND install it into basic system.
• once only failed to build packages are left in the list, attempt to build them using same procedure, until entire list of failed packages is processed twice with zero packages succesfully compiled.
• report to programmer which package failed to build

Screwup can happen in following situations:

• Slackbuild doesn't return error code (which quite possible, but can be fixed).
• Instead of failing, configure disables some functionality when required library is not found.

Problems:

• requires separate partition with a lot of space.

Pretty stupid, simple and straightforward approach, which will work for huge portion of the packages and can be automated. Now point out errors.

Can be bypassed by adding TWO or more slackbuilds to the list which will produce same package, but second version will overwrite first.

Because when oldest distribution was built manually for all those years, this is wrong. And it is wrong, because it is incredibly inefficient.

No I don't. You are perfectly aware that offer of services is forbidden by the forum rules.

Do you seriously think that I am that stupid?
I "demand" nothing. I tried to explain my position clear enough, but unfortunately as soon as someone mentionts money/contract/job, people gets paranoid, radically switch their way of thinking, start seeing crooks everywhere and decide that you are greedy bastart that wants their money.
--EDIT--
By the way, where did "demand" part come from? I surely didn't say something "pay me, or I will destroy the planet".

Short explanation:
Such script would be a very good to have. Because you could easily maintain collection of slackbuilds, tweak some of them and easily deploy fork when necessary. But such script doesn't exist. I think I could create this, but problem is not interesting, and I will not receive any "payback" of this (not only money. No satisfaction, no fun, nothing, no people using this, etc). Which means this thing will be probably never created. Which is bad.