<div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif"><span style="font-family:arial,sans-serif">On Mon, Aug 28, 2017 at 9:31 AM, David Spencer </span><span dir="ltr" style="font-family:arial,sans-serif"><<a href="mailto:baildon.research@googlemail.com" target="_blank">baildon.research@googlemail.com</a>></span><span style="font-family:arial,sans-serif"> wrote:</span><br></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
</span>Hmm, can I change my mind on that?<br>
<br>
I'm wrong, and as you initially said Eric, this would be the only<br>
thing on SBo that absolutely requires x86_64 + multilib. Everything<br>
else will work on either normal i?86, or normal x86_64. The other<br>
admins are nervous about this -- and testing it would be difficult for<br>
us.  So I don't think we can accept unity-editor, sorry :(<br>
<br>
However, thanks for asking, for me it raises another question. Can /<br>
should we help to find a way of making interesting SlackBuilds outside<br>
of SBo more discoverable?<br>
<br>
Thanks<br>
<div class="HOEnZb"><div class="h5">-D.<br></div></div></blockquote><div><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">​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.</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">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.</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">If you want more of a dissociation between <a href="http://slackbuilds.org">slackbuilds.org</a> packages and multilib packages like this one, all you need is an extra IP, a vhost, and extra repo.  Just stand up a <a href="http://multilib.slackbuilds.org">multilib.slackbuilds.org</a> site on the same host that has the same architecture as <a href="http://slackbuilds.org">slackbuilds.org</a> 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.</div></div></div></div>