@dugan Why do you question and answer me as if you're the representative?

Because you asked and I know the answer. The fact that you ignored the answer is making me doubt your sincerity.

Oh sorry it seems that I haven't made it obvious in my header subject that I'm somehow wanting to know the opinion of the Slackware team themselves. You know the answer, because you're one of the representatives? Or do you expect it? How different is that to how I estimate that it could be likely that it would be rejected? Even I so I try for I know there's a valid point in it somehow.

Oh, and your meaning is that you did not want to hear from anyone else? Then you shouldn't have posted here at all. You should have contacted them directly.

To be sure that you measure the amount of work that would need, I suggest that you do it yourself for only one CPU type.

The fact that Slackware packages are built individually, and there's no automated process to build them all at once, obviously makes this proposal even more difficult to implement.

I made a choice to ask in a bit more casual manner like in this forum rather than bothering them directly. As for other people's opinion I am open to it. And I mean opinion, not affirmations.

You asked a yes/no question. The answer is no. I'm not going to pretend that it's not the correct answer just because you're not open to "affirmations". That is not my problem.

I wonder. I actually see it to be only a script or two. If they already have something that automates the build of one release, changing the flag for it would just be easy.

But AFAIK, they do not, as Dugan just stated.

konsolebox, do you know that slackware is maintained by just one person?
I think you are missing this very important detail related to what you're asking for (and that is the reason of my previous post).

@ponce I won't mind just having an answer from his team as well.

They don't.

There is one script per package. Packages are updated and rebuilt on an individual basis in the process of developing the -current branch. A release is just a snapshot of -current. In a typical release, many packages will have not been rebuilt or updated since the previous release.

Yet that automation script could be made if it's not yet there if they decided to. It's pretty easy I think. As an example, even with the known utility src2pkg we could just have a list file or a formatted file of packages that could be parsed and call the utility continuously. Stop somewhere if it fails. Log redirections with tee -a. It's fairly easy actually. And it's rare for a build to fail just because a cpu type is changed.

If it's that easy please try it.