1 |
Hi, |
2 |
|
3 |
I'd be in support. Especially for "data only" kind of packages, like: |
4 |
|
5 |
net-misc/asterisk-moh-opsound |
6 |
net-misc/asterisk-extra-sounds |
7 |
net-misc/asterisk-core-sounds |
8 |
|
9 |
For all three these I've already dropped the DEPEND on net-misc/asterisk |
10 |
anyway, and upgraded the PDEPEND on net-misc/asterisk back onto these to |
11 |
RDEPEND. Other than that they really only install a bunch of audio |
12 |
files in various formats. |
13 |
|
14 |
One could even mark the various acct-{user,group}/* packages this way |
15 |
(although this is a simple eclass change). |
16 |
|
17 |
One challenge I foresee is that one could have a perl, python or php |
18 |
(script language of choice) package depend on a specific version of |
19 |
interpreter, which may not be stable for given arch. So may require |
20 |
some special handling in terms of dependencies. |
21 |
|
22 |
Kind Regards, |
23 |
Jaco |
24 |
|
25 |
|
26 |
On 2020/03/18 16:54, William Hubbs wrote: |
27 |
> All, |
28 |
> |
29 |
> this came up again on the recent thread about dropping non x86/amd64 |
30 |
> support for python packages, and I want to bring it up again on its own |
31 |
> thread. |
32 |
> |
33 |
> How often do architecture specific bugs really exist in languages like |
34 |
> perl, python etc? From what I've seen they are pretty rare. Not to mention, |
35 |
> if we found one somewhere, we could adjust keywords as necessary. |
36 |
> |
37 |
> Also, if someone did inadvertently keyword a package with noarch that didn't |
38 |
> work everywhere, it would be a matter of adjusting the keywords for that |
39 |
> package. |
40 |
> |
41 |
> So, my question is, why can't we add a noarch/~noarch keyword and see |
42 |
> how things go? If it gets abused we can always nuke it later. |
43 |
> |
44 |
> Thanks, |
45 |
> |
46 |
> William |
47 |
> |