SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I am aware of this. What I am looking for is sbopkg functionality in slackpkg. Similar to NetBSDs pkgsrc where i can build packages from source or install binary packages.
to use it you need as dependencies other utilities (namely slapt-src and slapt-get),
it is very unlikely that such a tool be ever included in Slackware.
As ponce's answer imply, there is no, and probably never will, a repository shipping packages built from SlackBuilds hosted @ http://slackbuilds.org and endorsed by slackbuilds.org.
Be aware that regardless of the tools used there is no simple way to guarantee that a package build from a SlackBuild not included in Slackware doesn't interfere with another third-party package.
The reason is that to be sure of that one need to install successively all available third party packages and see if a to-be-installed package overwrites files provided by an already installed package. Any volunteer?
It doesn't exist right now and it won't unless someone decides to code it like they did with slackpkg+. slackpkg is only designed to download pre-compiled binaries and install them. It doesn't have anything in there to handle SlackBuild files.
However, if you're just wanting SBo packages installed onto your computer using slackpkg, you could use the slackonly repo. It isn't endorsed or supported by SBo, but it builds all the packages on SBo and provides them in a repo that slackpkg can use. That's about as close as you're going to get with what currently exists.
If you want one tool that can compile programs from SBo, install official Slackware updates, and install packages from other repos, there is slpkg. I've never used it, so I can't give advice one way or another, but it is one option.
Thanks for the replies and information. I was expecting that nothing like this exists but I was curious nevertheless.
I always liked NetBSD's pkgsrc and even installed it on Slackware once years ago. Since I startet using slackpkg+ for my own packages, I always wondered if there is an extension to slackpkg to compile from source. That one could configure slackpkg to use his own repo of slackbuilds or let's one use the SBo repo.
I gave sbopkg and slpkg a try before and I liked both of them. But as I only use a handful of 3rd party packages that I create with my own build scripts, this is not the tools that I am looking for or need. I like slackpkg+ because I can use my own repository (the graylist is nice too), that it is an extension to slackpkg which is already part of Slackware and not a seperate tool like sbopkg or slpkg.
There's a technical problem with extending slackpkg -- you can't add new commands, because the extra functions are read after the command line arguments are parsed, so slackpkgplus is a big achievement within those limitations. Going further would need a minor change in slackpkg, but poor slackpkg has already been tortured enough in this development cycle.
For a small private collection of scripts, probably the best solution is to build manually, and maybe use Eric's gen_repos_files.sh to feed them into slackpkgplus. slackrepo is intended to automate that workflow, and theoretically (mostly untested ) it can build from almost any random pile of vaguely-slackbuildish scripts, but it's not really worth the effort of setting up and learning that unless you're already drowning in SlackBuilds.
The closest tools for slackpkg is sbopkg and sbotools. Sbotools is more akin to build tools used by FreeBSD, Gentoo, Funtoo, CRUX, and others. Sbopkg is more of a unique cued system, but both allow packages to be built using cues, dependency lists, and the packages work flawlessly with pkgtools.
Whilst I appreciate PN work, Slackonly still lacks dependency information for many packages. Users should track dependencies through SBo and download them from slackonly either manually or using third-party tools.
Whilst I appreciate PN work, Slackonly still lacks dependency information for many packages. Users should track dependencies through SBo and download them from slackonly either manually or using third-party tools.
Well Hosein, I don't know yet how the dependencies are fed in the REQUIRED fields e.g. in this PACKAGES.TXT but will investigate. All I know is what is written in the FAQ: "All packages are built and rebuilt using Slackrepo. Slackrepo is a software utility that tests to see that packages are built cleanly with all required dependencies.".
As Slint 14.2 will ship a full, although modified, Slackware installation, I just added as source in slapt-getrc this repo to see what happens and could get some packages installed and running.
I had no missing dependency yet, but I assume that if someone detects one the right thing to do would be to inform Panagiotis.
I had an issue though with one of these packages, namely wxPython:the CONFLICTS field is blank in PACKAGES.TXT, however it overwrited some files (from wxWidgets IIRC). I don't know what is the policy of SlackRepo about conflicts between two third-party packages (will ask) hence my remark in the post you quoted.
Have a good day.
PS I know that the package tools can inform about files that would be overwritten, just didn't pay attention. My bad. But I assume that I am not alone there, hence my concern. This is even more true when a package is installed as a dependency of another one (this was the case for wxPython).
Last edited by Didier Spaier; 06-09-2016 at 05:25 AM.
However, Panagiotis started rebuilding the repo against -current, aiming to provide proper dependency information. He also changed the tag for his packages to 'slonly'. The repository for -current looks much better now and he wants to keep it that way for the upcoming 14.2.
However, Panagiotis started rebuilding the repo against -current, aiming to provide proper dependency information. He also changed the tag for his packages to 'slonly'. The repository for -current looks much better now and he wants to keep it that way for the upcoming 14.2.
Thank you my friend. Yes, my information comes from working with 14.1. You are right, many dependency issues have been fixed in PACKAGES.TXT file for current. I will test it again as soon as 14.2 released.
@Didier
I am not sure about slapt-get but slpkg has this feature to inform user about already installed dependencies. However, even if users don't attend to such warnings, I think that would be harmless as long as packages gathered from same repository.
Hey folks, for the record it wasn't Panagiotis' fault that the slapt-get compatible deps were screwed up in slackonly -- it was my fault, a slackrepo bug, and as usual I took too long to get round to fixing it
I am not sure about slapt-get but slpkg has this feature to inform user about already installed dependencies. However, even if users don't attend to such warnings, I think that would be harmless as long as packages gathered from same repository.
Well, not sure about that. If by "same repo" you mean "checked by the same person who commits all changes", you are probably right as this person hopefully bears in mind the conflicts (that can be harmless or not).
Well known examples in Slackware are the packages that install libraries already shipped in aaa_elflibs (but Patrick takes care of making sure this doesn't hurt), and until the packaging changed, glibc that shippped files already shipped in other glibx-* packages for instance. The same is probably true for Salix and the checks made by George.
By the way these examples are not so similar: the files shipped in the new vs already installed packages are (or at least were) not the same in the case of aaa_elflibs but were the same in case of glibc-*. Whether they are identical or not can checked by the tools comparing the checksums, for instance.
But what if the repo ships thousands of packages built from SlackBuilds provided many people who are not aware of the other packages? Maybe slackrepo can do or help to do these checks then, I don't know. David, could you shed some light here?
Last edited by Didier Spaier; 06-09-2016 at 10:09 AM.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.