I second @LuckyCyborg it would be awesome if this made it into Slackware Current merged into slackpkg I for one have been using slackpkg+ alot with my home network and it allows me to keep things in separate repositories. As well as when Ktown was being developed it allowed alot of us to merge that into Slackware Current at the time.

1 members found this post helpful.

slackpkg is for Slackware tree only. slackpkg+ provides additional functionality for third party packages. Keep them separate. I'm actually fine the way it is, but fine if added to Slackware proper.

4 members found this post helpful.

It would be a nice addition, to be configured : I maintain several boxes for family and it would permit them to achieve alone a few trivial tasks of updating their machine.

With all respect, I see no reason for a remote packages manager to support exactly ONE TREE.

On contrary, if we want to ever break the curse of Holly Full Install and every Slacker to stop to install a full LAMP stack along one truck load of FTP and other God knows for what servers in their HTPC and people to install the Xorg stack in their LAMP servers just because, we need first of all a remote packages manager which support multiple trees.

In other hand, the single real excuse I heard for ONE TREE support in slackpkg is that that Slackers may arrive to blame Slackware for failed third party packages installed by it.

BUT, permit me to believe strongly in the Slackers' intelligence, and just like other millions of Linux users do, that they will accurately will figure out that a package not shipped by Slackware, it's in the end not shipped by Slackware but by someone else.

1 members found this post helpful.

Archlinux works the same way though
"pacman" does not support AUR

This does not mean that it is a good thing, but that it also exists for others

Out of curiosity I had a look at the list of supported repositories. I see this one among othersI wonder how users of slackpkg+ can use the packages in this repository, as the information about dependencies is provided in a form suitable for slapt-get, but as far as I know unusable by by other tools. This also applies to the repositories salixos, salixextra and slackel. So, what means "supported repositories" for these? Who is supposed to provide support? And as Slint includes some packages with the same name but not the same content as Slackware, I can't guarantee full compatibility of their dependents with Slackware 15.0.

For these reasons I would advise someone wanting to use Slint packages (as well as packages in the other repositories mentioned above) in another distribution to use slapt-get rather that slackpkg+, and only after a careful settings of the priorities in /etc/slapt-get/slapt-getrc.

1 members found this post helpful.

Why would "we" want to break this curse of the "Holly Full Install". I see it as a blessing. You have a complete distribution all dependencies are already resolved. By using slackpkg you can easily keep it that way. I've always had the view that slackpkg was designed with that in mind, a means to maintain Slackware against the Slackware tree and only that tree. You don't want to do a Full Install, then don't. Slacker's should be able to figure out what needs to be installed to meet what ever task they have in mind for Slackware.

Want to branch out and start using third party trees, then use the slackpkg add-on slackpkg+, or use one of the other third party package managers that are available. I don't like the idea of merging slackpkg and slackpkg+, keep them separate. If it is decided to add slackpkg+, then it should go in extra. I believe there are others in Slackware land who prefer just slackpkg or prefer other third party packages managers vice slackpkg+. As for myself, I prefer slackpkg with slackpkg+ in most of my systems. I do have Slackware installations the only use Slackware packages thus only slackpkg.

6 members found this post helpful.

As a matter of facts, the "pacman" supports well multiple remote binary package repositories, while AUR is a user packages repositories and publishes PKGBUILDs - it's rather similar with our SlackBuilds.org

Then this claim that "pacman does not support AUR" is rather moot. In the end, same could be said about about Debian's or Ubuntu's apt-get and being not capable to use package source repositories, even there are myriads of PPAs.

So let's keep distinct the discussions about binary and source remote repositories.

After all, even Gentoo does not support both in the same time.

SBo is officially supported by Slackware
There are, moreover, people who take care of the quality of the slackbuilds

This is not the case with third party repo.
Not that they are not of good quality, but just that they are not subject to control and approval
Maybe, this can be a blocking point to their inclusion

1 members found this post helpful.

SlackBuilds.org is a repository of scripts, not packages. It has no relation to slackpkg+.

1 members found this post helpful.

Yawn. The idea that our BDFL should hijack a third party project to create an official tool to handle third party software created with uncontrolled third party builds from uncontrolled third party repositories is farcical. Not least, there is potential for distribution of patent encumbered builds, a legal minefield best avoided.

What is so hard about installing slackpkg+ that it needs to be an official package?

6 members found this post helpful.

Slackpkg+ can use this repository because it has the necessary components available to validate that repository. What I am trying to say is since you signed all your packages and sharing a public gpg-key slackpkg+ look's at your packages as being validated by you who signed them. You also have slackpkg+ the checksums to verify and let the other users know who added ur repo to the config file that there could be updates to the same program that they have on there computer.

Thanks for the reminder

That's why you shouldn't have cut my quote and removed the most important part

And what you guys will do if @zerouno comes back in a bright day, just to tell "I was hired by Microsoft. So long and thanks for all fish!" ???

You will kiss goodbye the multiple repositories support on slackpkg ?

I expect you to take over the development then. Put your money where your mouth is.

4 members found this post helpful.