Re: [aur-general] PKGBUILD for an .AppImage

2018-10-13 Thread Tom Hale




On 12/10/18 12:06 am, Eli Schwartz via aur-general wrote:

The fundamental purpose of AppImage is to offer standalone software that
does not integrate with the package manager, in return for not depending
on the package manager.

What is the point of packaging one into a pacman package? If people
wanted appimages they would download them and run them as intended...
not by extracting the contents and incompletely copying them to /usr


The advantages I see of packaging an AppImage are:

* Automatic updates
* GUI integration (eg appname.desktop file and icon)
* Easy access to man pages, help docs and changelog
* Easy access to files (eg skeleton config files) specified in the help docs


Programs which build using private libraries belong in /opt either way,
definitively not in /usr/lib.


Cheers, I'll symlink to there.

--
Tom Hale


[aur-general] Become TU

2018-10-13 Thread Islam Bahnasy via aur-general
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


Hello,

I see that 'usbguard' is very useful tool and I depend on it my self so
I hope if it's merged to the community repo.
I never had a patch to any Arch project yet however I do have a lot of
passion towards becoming a TU and maintaining usbguard.

https://usbguard.github.io/

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEZTuDEAsuVmnVQRUQ10eBRotj8oQFAlvB8koACgkQ10eBRotj
8oQNKw//WIpNFGdOEqFCN6eKEr50XzleFZhAEkexa+iVq+gKxGyqwfnNRrXW+K2Q
hkP42G0okpIb3Q2PEL+7VLxARMVUSGtMByKHGZfx/SGsjOKbA5XWCoQxVBD9A/ZA
CB2hugkZpbW+qajv8jow92poYPOLgnUQfADMJ0c+rRbSdhu7I/+XjSfV8LA6agmR
uoLRZDfagEky5UOJhATG+2oQyxqrwpHB4r6CC/+avlNhg/OhHRaYeKo908NmOBMy
AOBSHdjWJFbaO7wlnwCjEymhoeNCgUly/NdugBYLzeSV1Vi+ZUGkgXj8jirgndVQ
BntW9Zmr/lRu3TU+tByO2jFV4mPtZeCKY/IAsWRfm6rmquzXKqbOS4zAxyX8fIjx
PdnDyR2AfTqpuYhJyFVBi9pCsTX9a94BRms9I0exkE6LwVGKfNvJww65+MTjvme/
U/4A/Qyu7D1UoG87mw23quqSu5evdjgGpM+0cB9WaVKVMTduObnDl7RQT+RhD1cL
uE/vxC5qgjghtTDBLKXN5WsxHRtZvbSgIeMaSsfYJQ5USNWJoQV+xTMUvFC8Zb/G
bKlCZ3MGwOXWGbLFuHHZPncSS21nHIi9VHjI2GU99LfLBvvsh62juMy6FbT07jhF
xco9zI63feLzOXgkdHpNM1xIXSKm8EtqHe623WfL7wONHDtcl4o=
=q2MX
-END PGP SIGNATURE-


Re: [aur-general] PKGBUILD for an .AppImage

2018-10-13 Thread Robin Broda via aur-general
On 10/13/18 2:06 PM, Tom Hale wrote:
> The advantages I see of packaging an AppImage are:
> 
> * Automatic updates

Automatic in what sense

> * GUI integration (eg appname.desktop file and icon)
> * Easy access to man pages, help docs and changelog
> * Easy access to files (eg skeleton config files) specified in the help docs

Why would that require AppImage in the loop?

Literally none of your points have anything to do with AppImages.

-- 
Rob (coderobe)

O< ascii ribbon campaign - stop html mail - www.asciiribbon.org


Re: [aur-general] Become TU

2018-10-13 Thread Robin Broda via aur-general
On 10/13/18 3:25 PM, Islam Bahnasy via aur-general wrote:
> 
> Hello,
> 
> I see that 'usbguard' is very useful tool and I depend on it my self so
> I hope if it's merged to the community repo.

I suggest just creating your own package repository.

-- 
Rob (coderobe)

O< ascii ribbon campaign - stop html mail - www.asciiribbon.org


Re: [aur-general] Become TU

2018-10-13 Thread Daniel M. Capella via aur-general
On October 13, 2018 9:25:31 AM EDT, Islam Bahnasy via aur-general 
 wrote:
>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA256
>
>
>Hello,
>
>I see that 'usbguard' is very useful tool and I depend on it my self so
>I hope if it's merged to the community repo.
>I never had a patch to any Arch project yet however I do have a lot of
>passion towards becoming a TU and maintaining usbguard.
>
>https://usbguard.github.io/
>
>-BEGIN PGP SIGNATURE-
>
>iQIzBAEBCAAdFiEEZTuDEAsuVmnVQRUQ10eBRotj8oQFAlvB8koACgkQ10eBRotj
>8oQNKw//WIpNFGdOEqFCN6eKEr50XzleFZhAEkexa+iVq+gKxGyqwfnNRrXW+K2Q
>hkP42G0okpIb3Q2PEL+7VLxARMVUSGtMByKHGZfx/SGsjOKbA5XWCoQxVBD9A/ZA
>CB2hugkZpbW+qajv8jow92poYPOLgnUQfADMJ0c+rRbSdhu7I/+XjSfV8LA6agmR
>uoLRZDfagEky5UOJhATG+2oQyxqrwpHB4r6CC/+avlNhg/OhHRaYeKo908NmOBMy
>AOBSHdjWJFbaO7wlnwCjEymhoeNCgUly/NdugBYLzeSV1Vi+ZUGkgXj8jirgndVQ
>BntW9Zmr/lRu3TU+tByO2jFV4mPtZeCKY/IAsWRfm6rmquzXKqbOS4zAxyX8fIjx
>PdnDyR2AfTqpuYhJyFVBi9pCsTX9a94BRms9I0exkE6LwVGKfNvJww65+MTjvme/
>U/4A/Qyu7D1UoG87mw23quqSu5evdjgGpM+0cB9WaVKVMTduObnDl7RQT+RhD1cL
>uE/vxC5qgjghtTDBLKXN5WsxHRtZvbSgIeMaSsfYJQ5USNWJoQV+xTMUvFC8Zb/G
>bKlCZ3MGwOXWGbLFuHHZPncSS21nHIi9VHjI2GU99LfLBvvsh62juMy6FbT07jhF
>xco9zI63feLzOXgkdHpNM1xIXSKm8EtqHe623WfL7wONHDtcl4o=
>=q2MX
>-END PGP SIGNATURE-

https://wiki.archlinux.org/index.php/Trusted_Users#How_do_I_become_a_TU.3F

-- 
Best,
polyzen


Re: [aur-general] PKGBUILD for an .AppImage

2018-10-13 Thread Jonathon Fernyhough
On 13/10/2018 14:34, Robin Broda via aur-general wrote:
> On 10/13/18 2:06 PM, Tom Hale wrote:
>> The advantages I see of packaging an AppImage are:
>>
>> * Automatic updates
> 
> Automatic in what sense
> 
>> * GUI integration (eg appname.desktop file and icon)
>> * Easy access to man pages, help docs and changelog
>> * Easy access to files (eg skeleton config files) specified in the help docs
> 
> Why would that require AppImage in the loop?
> 
> Literally none of your points have anything to do with AppImages.
> 

I believe Tom is pointing to the advantages of deploying an AppImage via
a PKGBUILD, rather than of the AppImage format itself. Essentially,
using an AppImage as a package `source` like an RPM/deb or other
non-native packaging archive.

I've seen some projects [citation needed] provide only an AppImage and
building from source is non-trivial, so being able to "package" the
AppImage could make it easier to use within Arch.



signature.asc
Description: OpenPGP digital signature


Re: [aur-general] PKGBUILD for an .AppImage

2018-10-13 Thread Robin Broda via aur-general
On 10/13/18 4:36 PM, Jonathon Fernyhough wrote:
> I believe Tom is pointing to the advantages of deploying an AppImage via
> a PKGBUILD, rather than of the AppImage format itself. Essentially,
> using an AppImage as a package `source` like an RPM/deb or other
> non-native packaging archive.

Then what he's referring to aren't the 'advantages of packaging an AppImage', 
but rather the advantages of packages as a whole - and even then it's not 
really accurate.
I don't think going off on a tangent about the benefits of system packages is 
relevant to the topic, anyways.


> I've seen some projects [citation needed] provide only an AppImage and
> building from source is non-trivial, so being able to "package" the
> AppImage could make it easier to use within Arch.

That's not the case here though, as we have source builds for the program in 
question.
If there are upcoming issues with the source build, those should be patched 
upstream or in the PKGBUILD instead of abandoning it in favor of a -bin package.

-- 
Rob (coderobe)

O< ascii ribbon campaign - stop html mail - www.asciiribbon.org


Re: [aur-general] PKGBUILD for an .AppImage

2018-10-13 Thread Eli Schwartz via aur-general
On 10/13/18 8:06 AM, Tom Hale wrote:
> The advantages I see of packaging an AppImage are:
> 
> * Automatic updates

Not only is this not automatic when using pacman or even when using an
AUR helper, the AppImage format has the ability to self-update via a UI
exposed within the application itself (see libappimageupdate) using a
manifest embedded within the AppImage. It also supports binary deltas.
Updates can be automatically run in the background or triggered by a popup.

> * GUI integration (eg appname.desktop file and icon)

appimaged will monitor your system for AppImages, and integrate them via
desktop files and icons.

> * Easy access to man pages, help docs and changelog

I have rarely ever seen a pacman package that makes use of changelogs,
and the ones I do see, are invariably changelogs for the PKGBUILD
itself, not for the program.

Please do explain how AppImages as sources, over any other type of
source, are *more* likely to have any of the three. I wasn't aware it
was customary to provide those in AppImages. Probably due to the format
being all about isolation vs. natively integrating with the system.

> * Easy access to files (eg skeleton config files) specified in the help
> docs

What applications actually provide skeleton config files? The defaults
will be buried in program logic and written out by functions that
interpret the format in the first place -- skeleton configs would be
rather bloated and pointless according to that logic, and if you just
want documentation on the default values, then most programs either
document that, come with options to reset to defaults, or in the
worst-case scenario, allow you to blow away your settings.

There's an incredible degree of inconsistency within the general
application ecosystem, between programs which have no default config
files and only write out the settings which are non-default, programs
which have an embedded scripting language in which all configuration
must be *programmed*, programs which store their configurations as some
weird binary format (I'm looking at you, gtk/gnome), or simply programs
where the defaults are obtained by blowing away your configuration, then
starting the program.

Occasionally, a program even comes with skeleton config files. o_O
Although one of those programs, GnuPG, actually stopped on the grounds
that they get stale and since they're nothing but documentation, they
should simply ship as documentation, not skel files which contain copies
of the documentation. This is a healthy attitude.

-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature