You are not logged in.

#1 2007-09-10 12:33:30

dongiovanni
Member
From: Germany
Registered: 2006-10-06
Posts: 110

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

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 ? hmm

thanks, dongiovanni

Offline

#2 2007-09-10 13:06:21

natalian
Member
Registered: 2007-09-06
Posts: 29

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

no you cannot, if you want me to host it i will

Offline

#3 2007-09-10 13:19:38

dongiovanni
Member
From: Germany
Registered: 2006-10-06
Posts: 110

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

Ok, thanks! That would be very nice big_smile

Offline

#4 2007-09-12 16:09:56

ezzetabi
Member
Registered: 2006-08-27
Posts: 947

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

natalian, can you argument your answer a little? Maybe pointing to the rule?

Offline

#5 2007-09-12 17:36:57

shining
Pacman Developer
Registered: 2006-05-10
Posts: 2,043

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

ezzetabi wrote:

natalian, can you argument your answer a little? Maybe pointing to the rule?

It took me 30s to find it.
http://wiki.archlinux.org/index.php/AUR_User_Guidelines

After logging in to the AUR web interface, a user can submit a tarball (tar.gz) of a directory containing build files for a package. The directory inside the tarball should contain a PKGBUILD, any .install files, patches, etc (ABSOLUTELY no binaries).


pacman roulette : pacman -S $(pacman -Slq | LANG=C sort -R | head -n $((RANDOM % 10)))

Offline

#6 2007-09-12 19:20:09

ezzetabi
Member
Registered: 2006-08-27
Posts: 947

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

We know about binaries (read the first post), but `binary' usually means executable files, isn't it?
Otherwise every file is binary as sequence of bytes.

Offline

#7 2007-09-12 19:27:25

Cerebral
Forum Fellow
From: Waterloo, ON, CA
Registered: 2005-04-08
Posts: 3,108
Website

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

ezzetabi wrote:

We know about binaries (read the first post), but `binary' usually means executable files, isn't it?
Otherwise every file is binary as sequence of bytes.

'binary' generally means non-human-readable, as in the distinction between 'binary' and 'text' files.

-edit- Wikipedia summarizes it nicely:

Many binary file formats contain parts that can be interpreted as text; binary files that contain only textual data - without, for example, any formatting information - are called plain text files. In many cases, plain text files are considered to be different from binary files because binary files are made up of more than just plain text.

Last edited by Cerebral (2007-09-12 19:29:12)

Offline

#8 2007-09-13 06:33:37

ezzetabi
Member
Registered: 2006-08-27
Posts: 947

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

Ok, I understood. But I still think there is something imprecise at least. The rule should be wrote better and the why about it would be even better...

This definition means a static HTML file is not a text file since it does have formatting information... for example.

This difference actually existed only because every OS used a different character(s) for meaning `new line,' and this forced users to change the files when passing from an OS to an other.
Just think to notepad.exe of Windows that is unable of open Linux text files since it does not understand the newline...

Last edited by ezzetabi (2007-09-13 06:34:43)

Offline

#9 2007-09-13 09:41:46

natalian
Member
Registered: 2007-09-06
Posts: 29

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

notepad cannot what? what are you talking about? it doesn't display it correctly, but that doesn't stop it being opened ...
the way i see it, and i think this is the way python distinguishes as well, is .. any file containing a NULL Byte  is binary regardless of the remaining content, so a tar.gz is binary as is an elf binary .. i do not see the point of discussion this here it has nothing to do with the post which has long been resolved .. i think it would be better to move this discussion to a thread of its own where much needed input can be gathered as i think this topic is a very interesting one indeed .. i.e are images considered binary as well? to me they are .. but are they allowed ? hmmm ..

Offline

#10 2007-09-13 11:07:16

mucknert
Member
From: Berlin // Germany
Registered: 2006-06-27
Posts: 510

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

The distinction is more a philosophical one than a clear technical distinction. "Binary" in the sense that is used here means executable files and libraries. This includes ELF files, Java Bytecode and stuff like that. Python scripts on the other hand can be executed but they are still human-readable because the bits and bytes in such a file translate into human-readable text according to a coding-pattern (ASCII or EBCDIC spring to mind) and therefore the term "binary" does not apply to them, same goes for HTML files. Both need "binaries" to actually get executed: the interpreter.
Pictures can't be translated into human-readable files in the sense that this a bit means something according to the e.g. ASCII. But on the other hand, they can not be executed (or they shouldn't be executed wink) and therefore do not qualify as "binaries" of the meaning above. They are in binary format but they are not executables or libraries and also need an interpreting "binary" to have a meaning whatsoever.

But enough of this. This does not belong in this thread really and shame on me for going on with this. I just wanted to put a dent into ezzetabis nitpicking. tongue

Last edited by mucknert (2007-09-13 11:08:15)


Todays mistakes are tomorrows catastrophes.

Offline

#11 2007-09-13 11:29:05

natalian
Member
Registered: 2007-09-06
Posts: 29

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

i get what you mean, but when i said python, i meant, the interpreter; when it loads a file ... it needs to be able to tell whether its binary or text file . afaik one way of telling is to look for NULL Bytes .. they do not appears in text files because text is considered human readable as you stated, however we do not use the entire ascii table in our writing .. afterall, who know what a null character looks like? lol

Offline

#12 2007-09-13 17:33:14

ezzetabi
Member
Registered: 2006-08-27
Posts: 947

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

@natalian
If you write a text using and save using UTF-16 encoding you'll do have null characters and I am pretty sure it is *still* text...

@muchnert
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.
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...

And anyhow, the question is `Why no binaries?'

Offline

#13 2007-09-13 18:46:29

mucknert
Member
From: Berlin // Germany
Registered: 2006-06-27
Posts: 510

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

ezzetabi wrote:

@muchnert

It's mucknert! Damn you! wink

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. tongue 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.


Todays mistakes are tomorrows catastrophes.

Offline

#14 2007-09-13 19:46:37

ezzetabi
Member
Registered: 2006-08-27
Posts: 947

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

Security? You mean I can't put a binary file directly in the aur since we can't (easily) read it, but I can put it in the source array so the makepkg downloads it, this make it more readable? And I am the only one that finds it strange?

About compiling and interpreting, what you said is of course correct. But you missed the point that was about the `result' same input -> same output (if the compiler and the interpreter uses the same interpretation of C standard and the program itself is not ill-formed)... Really, I do know this stuff... believe what you like.
Yet... Yes surely the source code is more readable big_smile

Last edited by ezzetabi (2007-09-13 19:51:11)

Offline

#15 2007-09-13 19:56:49

mucknert
Member
From: Berlin // Germany
Registered: 2006-06-27
Posts: 510

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

ezzetabi wrote:

Security? You mean I can't put a binary file directly in the aur since we can't (easily) read it, but I can put it in the source array so the makepkg downloads it, this make it more readable? And I am the only one that finds it strange?

I guess you have a point here. However, I said that this is _one_ reason I can imagine. You could always check the source-array and consider for yourself. In other words: it's a lot easier to check if the actual online source of some bins is trustworthy or not than some bins in an uploaded archive. The weak link is always the user and I can understand the Arch-TUs when they don't want to open up another way of compromising the system. Because you can use the PKGBUILD to pull in untrustworthy stuff does not mean that you should be allowed to upload the untrustworthy stuff right onto their servers. So your argument is pretty faulty in that respect.

Also imagine the increased size of a tarball containing binaries. Even compressed they are considerably larger than compressed text files because of the very nature of text and executables/libraries. This would all count towards space and bandwidth-usage which the project has to pay for, too. Just an idea though.

I guess that there is no single answer to the question "Why no binaries?" but instead a combination of several issues. One aspect might be security, another one the increased size of the files, another one might be legal issues about redistribution and so on. If you combine them all together it seems more feasible to just prohibit usage of binaries in the AUR-tarballs then to be forced to pick the good from the bad. Makes sense to me.

ezzetabi wrote:

About compiling and interpreting, what you said is of course correct. But you missed the point that was about the `result' same input -> same output (if the compiler and the interpreter uses the same interpretation of C standard and the program itself is not ill-formed)... Really, I do know this stuff... believe what you like.
Yet... Yes surely the source code is more readable

And you miss the point that the outcome is not important at all. It is the format that matters and that was everything that I was refering to. Of course the result might be the same but so what? That's like saying that walking and driving a car is the exactly same thing because it gets you from A to B. But they are still different in the way of achieving said result.
And I have learned to not trust people that tell me to believe them. That's what sheep do.

Last edited by mucknert (2007-09-13 20:00:45)


Todays mistakes are tomorrows catastrophes.

Offline

#16 2007-09-13 20:03:52

Cerebral
Forum Fellow
From: Waterloo, ON, CA
Registered: 2005-04-08
Posts: 3,108
Website

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

Maybe it's because we'd rather not host unverified binary content?  I'm not sure why the rule was instated, but that sounds reasonable.

Offline

#17 2007-09-15 20:41:54

Snowman
Developer/Forum Fellow
From: Montreal, Canada
Registered: 2004-08-20
Posts: 5,212

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

It's also possible that the "no binary" rule is just to emphasize the fact that only the PKGBUILD and files necessary to build the package are to be submitted to AUR, i.e. no precompiled package, no source tarball, no content of $startdir.

There are exceptions to that rule,for example when the source tarball doesn't contain an icon or the icon is in Windows .ico format. Then, an icon grabbed somewhere else on the Web or the converted icon can be included in the AUR tarball.

Offline

Board footer

Powered by FluxBB