I'd be in support.  Especially for "data only" kind of packages, like:


For all three these I've already dropped the DEPEND on net-misc/asterisk
anyway, and upgraded the PDEPEND on net-misc/asterisk back onto these to
RDEPEND.  Other than that they really only install a bunch of audio
files in various formats.

One could even mark the various acct-{user,group}/* packages this way
(although this is a simple eclass change).

One challenge I foresee is that one could have a perl, python or php
(script language of choice) package depend on a specific version of
interpreter, which may not be stable for given arch.  So may require
some special handling in terms of dependencies.

Kind Regards,

On 2020/03/18 16:54, William Hubbs wrote:
> All,
> this came up again on the recent thread about dropping non x86/amd64
> support for python packages, and I want to bring it up again on its own
> thread.
> How often do architecture specific bugs really exist in languages like
> perl, python etc? From what I've seen they are pretty rare. Not to mention,
> if we found one somewhere, we could adjust keywords as necessary.
> Also, if someone did inadvertently keyword a package with noarch that didn't
> work everywhere, it would be a matter of adjusting the keywords for that
> package.
> So, my question is, why can't we add a noarch/~noarch keyword and see
> how things go? If it gets abused we can always nuke it later.
> Thanks,
> William

Reply via email to