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

Eric Pratt eric.b.pratt at gmail.com
Mon Aug 28 16:06:02 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.slackbuilds.org/pipermail/slackbuilds-users/attachments/20170828/6d34bd97/attachment.html>


More information about the SlackBuilds-users mailing list