/usr/src/$pkgname-$pkgver doubts

[lmello]

Salix claims to be fully Slackware compatible, yet there's something slkbuild does that I personally find weird - it populates the /usr/src subtree with folders that contain only the SLKBUILD file and sometimes the build script it generates. No 'standard' Slackware package puts anything there, except the linux kernel source.

Why? Wouldn't it be enough to put the SLKBUILD file in /usr/doc/$pkgname-$pkgver, like the policy at slackbuilds.org does with the .SlackBuild file?

[damNageHack]

Why? Wouldn't it be enough to put the SLKBUILD file in /usr/doc/$pkgname-$pkgver, like the policy at slackbuilds.org does with the .SlackBuild file?

Good point. But do you know the packaging rules of Salix? Maybe I am wrong, but this has nothing to do with backwards compatibility, you can always use the original Slackware packages or some third-party packages instead of the ones from the official Salix repository. AFAIK The packages are and will be always Slackware compatible and therefore interchangable between each others
Personally, I think SLKBUILD is a source file and therefore should be put unter /usr/src like it is, it contains not only build script, as well also where you can get the source from and documentation stuff etc. A SlackBuild is a script and therefore only for build purpose.
But correct me please, if I am wrong in some point.

[lmello]

I think that a SLKBUILD falls in the same category of a SlackBuild - a build tool. And thus, organization-wise, should go in the same place.

I know the Salix packages are already backward-compatible with Slackware and its 'children', but I think that this file should be put in /usr/doc. After all, it contains information on how the package was built (the ./configure flags, for example), it's not part of the source code. So why create a directory just to put the SLKBUILD in?

[damNageHack]

So why create a directory just to put the SLKBUILD in?

Because there *could* also be the source itself and some additionally needed files.
They *could* be specified with "source=" variable in the SLKBUILD.
I would probably suggest you to read the developers' documentation about SLKBUILD again (wiki).

[thenktor]

So why create a directory just to put the SLKBUILD in?

Why not? It does not hurt in any way. And as damnagehack already has pointed out: there could be additional files that are needed to create the package.

like the policy at slackbuilds.org does with the .SlackBuild file?

This is not Slackware original package standard, too.

No 'standard' Slackware package puts anything there

Most Slackware packages I know don't provide the package build script inside the package and I really don't like this fact. If I want to rebuild a package I first have to go to some Slackware source repo, get the needed files and then I can rebuild the package.
With our way everything that is needed can be found in /usr/src/$pkgname-$pkgver. Just go there and run slkbuild.

[pwatk]

Other distributions use /usr/src in this way, Arch Linux comes to mind, and BSD distributions uses it extensively.

It's a staging area for you to compile your own version of a given package and there is no need to include the entire source because it is downloaded for you by the SLKBUILD.

A scenario for you:

Problem: You have a package that is segfaulting all the time and you think you've found the answer (this could be a patch or an option in the configuration).

Solution: You already have the build script on your system in a convenient staging area under /usr/src so all you need to do now is make the changes you need to the SLKBUILD and execute slkbuild -X to create a shiny new package you can test out before posting your findings here.

What can be bad about this?

Besides, who's ever considered compiling a package in /usr/doc

[damNageHack]

Besides, who's ever considered compiling a package in /usr/doc

Besides, who's ever considered compiling a package in /usr/src
-> /home/user/build

[pwatk]

Well this was the first link I clicked after searching 'build package /usr/src':

Compiling SuSE Source Packages

[damNageHack]

Okay, I think of compiling the kernel under /usr/src. This makes the most sense to me cause of the dependency (headers), but I can not imagine any other package which *needs* to be build unter /usr/src directly.

[lmello]

Okay, I think of compiling the kernel under /usr/src. This makes the most sense to me cause of the dependency (headers), but I can not imagine any other package which *needs* to be build unter /usr/src directly.

I agree.