[aur-general] Tarball Guidelines

[PyroPeter]

On 12/04/2010 03:16 AM, Simon Stoakley wrote:
> The day was 03/12/10 21:24 when , Xyne had this to say......:
>> On 2010-12-03 20:33 +0100 (48:5)
>> Stefan Husmann wrote:
>>
>>> Am 03.12.2010 19:46, schrieb keenerd:
>>>> Officially, the tarballs uploaded to the AUR should be named after
>>>> their package, contain a directory named after their package, contain
>>>> no dot files and most importantly contain no binaries. Officially,
>>>> these requirements are very important.
>>>>
>>>> Here are a bunch of non-conforming packages. Maybe 90% of them. (A
>>>> few errors slip though my scanner.)
>>>>
>>>> Of the +700 packages with binaries, most are a simple desktop icon.
>>>> Should these be base64 encoded if someone can't find hosting?
>>>>
>>>> If no one can think of a better way to deal with the nonconforming
>>>> packages, I'll write a bot to post insulting comments. Personally, I
>>>> really like this solution. The AUR has always had a wild west
>>>> frontier / insane asylum feel to it. The less regulation, the better
>>>> it works. But a few well placed suggestions could help make the two
>>>> thousand maintainers do a better job.
>>>>
>>>> -Kyle
>>>>
>>>> http://kmkeen.com
>>>
>>> Hello,
>>>
>>> I think, icon files should be tolerated, and always have been (since
>>> I use
>>> Arch Linux), if there is a desktop file and no downloadable icon
>>> delivered
>>> upstream. Having desktop files which point to an icon but not having the
>>> icon itself does not make much sense to me.
>>>
>>> Yes, taken verbatim, icons fall under binaries. But the spirit behind
>>> the
>>> restriction is that binaries often meen "executable binaries" which are
>>> virtually always downloadable or build by the makepkg step.
>>>
>>> Regards Stefan
>>
>>
>> I agree with Stefan. Also, base64 encoding files would only increase
>> the size
>> of the package (however insignificantly) without any benefit.
>>
>> The "no binaries" rule really means "don't include compiled files,
>> large files,
>> sandwiches, or anything else that shouldn't be in here" :P
>>
>
> I to hope that icons as ok, I've tested base64 encoding with ine of my
> pkg's that has an icon in and the size increased by over a third (from
> 60223 B to 82412 B). Also worth mentioning is that i only included the
> icon when someone requested a .desktop file, and as Stefan mentioned
> they're a bit 'off' with no matching icon.
>
>> If no one can think of a better way to deal with the nonconforming
>>> packages, I'll write a bot to post insulting comments. Personally, I
>>> really like this solution.
>
> Please don't send me horrible comments!
>
> If anyone's interested I used this site for the encoding.
>
> http://www.motobit.com/util/base64-decoder-encoder.asp

The raw icon data gets encoded to approx. 4/3 of it's original size.
This is because base64 encodes 3 bytes to 4 printable characters.
(And it's only approximately 4/3 because the data is padded to have
a size that is a multiple of 3. You may have noticed the '=' at the end
of the encoded string)

-- 
freenode/pyropeter                          "12:50 - Ich drücke Return."