[Slackbuilds-users] Can I submit a slackbuild that requires multilib?
yth at ythogtha.org
Fri Sep 1 13:57:22 UTC 2017
> 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
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.
More information about the SlackBuilds-users