What can be included in the *tar.gz that will be uploaded to AUR?

Question

Hi all,
I read, that binaries shouldn't been uploaded to AUR, but what about other files like a tar.gz file?
I came to this question because I'm maintaining the splashy package. The "arch" theme can't be hosted further on the place, where it is now and I have no possability to host it. So my question is whether I can include it in the *tar.gz file, that I upload to AUR ?
thanks, dongiovanni

Answer 1

ezzetabi wrote:@muchnert
It's mucknert! Damn you!
ezzetabi wrote:Nice points, still it is imprecise and I think the wiki message need to be written better, and this is why that message is here.
After all you still need a text editor to `human read' a text file, maybe not a text editor but at least a file system driver you can't seriously watch directly the hard disk, it is not so different from a image editor to read a picture.
Yeah, that might be the case. But that does not add anything to the argument. Of course everything on a computer is stored in binary. That does not mean that everything is executable machine-code. This is where the argument is actually taking us: compiled, executable machine code. An image isn't and neither is a plain text file.
ezzetabi wrote:About interpreting and executing the difference is even more subtle, a C source file is a text, its compilated form is not, but I can use the C source file with an interpreter and have the same result...
How is that difference subtle? The C file is encoded according to some character encoding (e.g. ASCII) and therefore, it is a plain text file. If you compile it you get a whole new, different file that bears no resemblance to the source-file. It is a stream of bits and bytes that manipulate certain registers and other parts of the hardware according to the specifications of said hardware. It is executable. A library has exactly the same basic layout: it is a stream of bits and bytes that, when laid on the registers and the functional units of the hardware, invoke a certain behavior, much like a key does in a lock (only more complex). The blueprint of the key (the C source) could not do that. The key itself (the executable file) does. The only difference of a library to an executable is that it can't execute itself by e.g. calling it's name from a shell because it lacks the syscalls to initiate a standalone start.
And when you feed a C file to an interpreter, it compiles the file on the fly and feeds it to the hardware. It's not rocket science. The C file itself is not executable, the interpreter OTOH is because it is machine code. The interpreter takes the C file, interprets it and puts the bits and bytes on the register himself.
Don't get me wrong but I think you lack the basic understaning of how a Computer actually works.
As for the question why executable files and libraries should not be uploaded to the AUR: I can find one simple solution. Security. You can look at PKGBUILDs and see what they do. You can't do that with libs and executables. At least not easily. Case closed.