[Slackbuilds-users] Can I submit a slackbuild that requires multilib?

[Ythogtha]

> On Mon, Aug 28, 2017 at 9:31 AM, David Spencer <
> baildon.research at googlemail.com> wrote:
> 
> >
> > Hmm, can I change my mind on that?
> >
> > I'm wrong, and as you initially said Eric, this would be the only
> > thing on SBo that absolutely requires x86_64 + multilib. Everything
> > else will work on either normal i?86, or normal x86_64. The other
> > admins are nervous about this -- and testing it would be difficult for
> > us.  So I don't think we can accept unity-editor, sorry :(
> >
> > However, thanks for asking, for me it raises another question. Can /
> > should we help to find a way of making interesting SlackBuilds outside
> > of SBo more discoverable?
> >
> > Thanks
> > -D.
> >
> 
> ​Needless to say, that's disappointing.  I understand the large storage
> requirement is a concern.​  But I'd like to hope that not officially
> supporting multilib wouldn't translate into a ban.  Considering that there
> is a real need for multilibed systems and software and that Slackware 64
> was setup to make it easy to multilib, it's always struck me as odd that
> SBo's multilib stance has been one of non-support.
> 
> I'd like to see something different happen with multilib here.  Even if the
> lack of official support remains, I'd like to see a more permissive
> policy.  For instance, add a multilib flag to the .info files that would
> mark a package as requiring multilib that could be checked during testing.
> If multilib is required, the test box could skip over it and the web page
> for that slackbuild would be marked as unsupported and requiring multilib.
> Then you could allow people on the mailing list to give a best-effort
> support if they wish.
> 
> If you want more of a dissociation between slackbuilds.org packages and
> multilib packages like this one, all you need is an extra IP, a vhost, and
> extra repo.  Just stand up a multilib.slackbuilds.org site on the same host
> that has the same architecture as slackbuilds.org but only hosts packages
> requiring multilib.  It would always be small but would make it easy to
> host multilib-only packages for Slackware users.  Tools that add more
> automation to slackbuilds, like sbopkg, could be updated to support
> multiple repos, like slackpkplus does.

	There is at least another slackbuild which'll work on a multilib
environment only. It exists because it also works on a pure x86 environment,
x86_64 is marked as UNSUPPORTED.
It's wine, and it can be built on a multilib x86_64 machine, by activating
multilib shell environment, and removing UNSUPPORTED from the DOWNLOAD_64 on
wine.info.
	Although it is still not supported by SBo.

	Does your package works on a 32-bit environment ?
If so, you could still submit and maintain it, with a README.x86_64 that
explains how to build it on an x86_64 multilib environment.
	It'll be up to everybody to read it and do it properly, while problems
still won't be supported by SBo.

Yth.