1 |
>>>>> On Sat, 06 Oct 2018, Mykyta Holubakha wrote: |
2 |
|
3 |
> Signed-off-by: Mykyta Holubakha <hilobakho@×××××.com> |
4 |
|
5 |
> I'm proposing to add a new eclass: appimage.eclass, to facilitate |
6 |
> extraction off AppImage bundles. The rationale is that some upstreams |
7 |
> have migrated to distributing their proprietary software exclusively as |
8 |
> AppImage bundles. (for instance dev-util/staruml-bin). |
9 |
|
10 |
Ask upstream to use a friendlier package format? |
11 |
|
12 |
> An example ebuild can be seen at https://git.io/fx3Mg |
13 |
|
14 |
> I'd like to ask the following questions: |
15 |
|
16 |
> 1. Can I put myself and proxy-maint under @MAINTAINER (or do I need to |
17 |
> find a gentoo dev)? |
18 |
|
19 |
You should contact proxy-maintainers in any case, because somebody needs |
20 |
to commit it for you. |
21 |
|
22 |
> 2. Are we OK with executing AppImage bundles downloaded from the |
23 |
> Internet (an alternative would be to implement a proper extractor |
24 |
> program, which would unpack the images without executing them, and add |
25 |
> it to DEPENDs). |
26 |
|
27 |
These are ELF binaries unpacking an included ISO 9660 image, right? |
28 |
Not sure if it's a good idea to execute those in src_unpack. Won't they |
29 |
require external dependencies to run? |
30 |
|
31 |
I have also looked at staruml-bin-3.0.2.ebuild (your example above) and |
32 |
I believe that it is highly problematic from a license point of view. |
33 |
The distfile includes bundled LGPL libraries without including their |
34 |
source, which means that it cannot be distributed. |
35 |
|
36 |
> --- |
37 |
> eclass/appimage.eclass | 69 ++++++++++++++++++++++++++++++++++++++++++++++++++ |
38 |
> 1 file changed, 69 insertions(+) |
39 |
> create mode 100644 eclass/appimage.eclass |
40 |
|
41 |
> diff --git a/eclass/appimage.eclass b/eclass/appimage.eclass |
42 |
> new file mode 100644 |
43 |
> index 00000000000..454bdedc07b |
44 |
> --- /dev/null |
45 |
> +++ b/eclass/appimage.eclass |
46 |
> @@ -0,0 +1,69 @@ |
47 |
> +# Copyright 2018 Gentoo Foundation |
48 |
|
49 |
This should be "Gentoo Authors" by the new copyright policy. |
50 |
|
51 |
> +# Distributed under the terms of the GNU General Public License v2 |
52 |
> + |
53 |
> +# @ECLASS: appimage.eclass |
54 |
> +# @MAINTAINER: |
55 |
> +# maintainer-wanted@g.o |
56 |
> +# @AUTHOR: |
57 |
> +# Mykyta Holubakha <hilobakho@×××××.com> |
58 |
> +# @BLURB: convenience eclass for extracting AppImage bundles |
59 |
> +# @DESCRIPTION: |
60 |
> +# This eclass provides a src_unpack function to extract AppImage bundles |
61 |
> + |
62 |
> +case "${EAPI:-0}" in |
63 |
|
64 |
The quotes are not needed. |
65 |
|
66 |
> + 6|7) |
67 |
> + ;; |
68 |
> + *) |
69 |
> + die "EAPI ${EAPI:-0} is not supported" |
70 |
> + ;; |
71 |
> +esac |
72 |
> + |
73 |
> +EXPORT_FUNCTIONS src_unpack |
74 |
> + |
75 |
> +# @VARIABLE: APPIMAGE_EXTRACT_DIR |
76 |
> +# @DEFAULT_UNSET: squashfs_root |
77 |
|
78 |
@DEFAULT_UNSET doesn't take any parameters. |
79 |
|
80 |
> +# @DESCRIPTION: |
81 |
> +# This variable specifies the directory, in which the AppImage bundle |
82 |
> +# is expected to be extracted. |
83 |
> + |
84 |
> +# @VARIABLE: APPIMAGE_EXTRACT_DEST |
85 |
> +# @DEFAULT_UNSET: ${P} |
86 |
> +# @DESCRIPTION: |
87 |
> +# This variable specifies the directory, to which the extracted image |
88 |
> +# will be moved. |
89 |
> + |
90 |
> +# @FUNCTION: appimage_src_unpack |
91 |
> +# @DESCRIPTION: |
92 |
> +# Unpack all the AppImage bundles from ${A} (with .appimage extension). |
93 |
> +# Other files are passed to regular unpack. |
94 |
> +appimage_src_unpack() { |
95 |
> + debug-print-function ${FUNCNAME} "${@}" |
96 |
> + |
97 |
> + local extract_dir="${APPIMAGE_EXTRACT_DIR:-squashfs-root}" |
98 |
> + local extract_dest="${APPIMAGE_EXTRACT_DEST:-${P}}" |
99 |
> + |
100 |
> + local f |
101 |
> + for f in ${A} |
102 |
> + do |
103 |
> + case "${f}" in |
104 |
|
105 |
No quotes here. |
106 |
|
107 |
> + *.appimage|*.AppImage) |
108 |
> + cp "${DISTDIR}/${f}" "${WORKDIR}" |
109 |
|
110 |
Add "|| die". |
111 |
|
112 |
> + debug-print "${FUNCNAME}: unpacking bundle ${f} to ${extract_dest}" |
113 |
> + chmod +x "${f}" \ |
114 |
> + || die "Failed to add execute permissions to bundle" |
115 |
> + "${WORKDIR}/${f}" --appimage-help >/dev/null 2>/dev/null \ |
116 |
> + || die "Invalid AppImage bundle" |
117 |
> + "${WORKDIR}/${f}" --appimage-extract >/dev/null 2>/dev/null \ |
118 |
> + || die "Failed to extract AppImage bundle" |
119 |
|
120 |
See above, presumably it would be better to use an external tool for |
121 |
extraction. |
122 |
|
123 |
> + rm -f "${f}" || die "Failed to remove bundle copy" |
124 |
> + mv "${extract_dir}" "${extract_dest}" \ |
125 |
> + || die "Failed to move AppImage bundle to destination" |
126 |
> + ;; |
127 |
> + *) |
128 |
> + debug-print "${FUNCNAME}: falling back to unpack for ${f}" |
129 |
> + unpack "${f}" |
130 |
> + ;; |
131 |
> + esac |
132 |
> + done |
133 |
> +} |
134 |
> + |
135 |
> -- |
136 |
> 2.15.1 |