Pre-Compiled Packages

[woodsman]

Hi folks,

Suggestion:

One of the distinct disadvantages many reviewers note about Slackware is the lack of a large repository of pre-compiled packages.

This request might be beyond the scope of Salix, but related is how to install pre-compiled third-party packages. The default repositories in gslapt are pre-compiled packages from the stock Slackware and Salix, but no direct support for third-party pre-compiled packages. Perhaps the quality of some packages at slacky.eu and linuxpackages.net is a concern for Salix developers. Perhaps then there should be a help file easily available how to enable such support. The gslapt Help menu is a good choice to hook that kind of information.

For example, consider providing the VirtualBox Guest Additions and associated rc.d scripts as pre-built Slackware/Salix packages.

Refer to slacky.eu or slackbuilds.org for examples. I realize most people who use VirtualBox already have a copy of the Guest Additions CD image and know how to install those tools. Yet one of the Slackware traditions is installing software with the package model rather than freelance installations. The former model provides a convenient method for removing software while the latter method does not.

For any long-term virtual machine, I would much rather install the guest additions as packages rather than run the VirtualBox installation script.

The lack of a large central Slackware repository is not a Salix specific problem, but one I think the Salix community shares with other Slackers.

[gapan]

Perhaps the quality of some packages at slacky.eu and linuxpackages.net is a concern for Salix developers.

That is indeed the main concern.

Perhaps then there should be a help file easily available how to enable such support.

There is. The slapt-get FAQ.

The gslapt Help menu is a good choice to hook that kind of information.

This should be directed upstream.

For example, consider providing the VirtualBox Guest Additions and associated rc.d scripts as pre-built Slackware/Salix packages.

Not something we would like to do. I don't think there are any VirtualBox Salix users, just VirtualBox Salix testers, which is a completely different thing and testers always know to install the guest additions if they want them. Furthermore, Salix in virtualbox runs just fine.

Refer to slacky.eu or slackbuilds.org for examples. I realize most people who use VirtualBox already have a copy of the Guest Additions CD image and know how to install those tools. Yet one of the Slackware traditions is installing software with the package model rather than freelance installations. The former model provides a convenient method for removing software while the latter method does not.

I don't understand what the "package" model or the "freelance" model are.

For any long-term virtual machine,

Does such a thing really exist? And people that don't know how to install the guest additions use VirtualBox in such capacity? I really doubt that.

The lack of a large central Slackware repository is not a Salix specific problem, but one I think the Salix community shares with other Slackers.

This is one of the problems we're trying to fix with Salix.

[thenktor]

Perhaps the quality of some packages at slacky.eu and linuxpackages.net is a concern for Salix developers.

Yes! But not only concerns. There may be real problems, e.g. if Salix and slacky.eu provide a same package "A" but only slacky.eu provides a package "B" that depends on "A". Due to different configure/build options of package "A" in both repos it is possible that package "B" won't work with Salix' "A" package.
Hope you got the point
Of course everybody can feel free to use third party repositories, but they won't be added to default slapt-get configuration because we can not offer support for those kind of errors.

[caitlyn]

The best solution is the one Vector Linux uses: recruit volunteer packagers and slowly build up a Salix-specific repository. The 32-bit repository already has some nice non-standard Slackware packages. 64-bit has fewer.

Seriously, if you end up building a package for yourself, which isn't much more work than compiling the software in the first place, build it to Salix standards and contribute it. I hope to do that with a handful of packages myself. If enough people do that you'll eventually have a really nice repository.

[gapan]

The best solution is the one Vector Linux uses: recruit volunteer packagers and slowly build up a Salix-specific repository. The 32-bit repository already has some nice non-standard Slackware packages. 64-bit has fewer.

That's exactly what we're doing already, or what we're trying to do anyway. I personally think we're already successful at doing it. And the difference between 32bit and 64bit repos is not that big. Currently there are 852 packages in the 32bit repo and 747 packages in the 64bit repo. Several of the ones that are missing are specific to 32bits, like wine, or google-earth, so the real difference is even smaller. I might call some of the other ones superfluous too, yet another image browser/audio player cases. And if something is missing from the 64bit repository that a user wants, he can always make a package request in the relevant section.

[damNageHack]

For example, consider providing the VirtualBox Guest Additions and associated rc.d scripts as pre-built Slackware/Salix packages.

I do not see any advantage in doing such a thing. What happens if you change your kernel version? Anyway, you will have to rebuild at least the modules. Providing a package for the Salix standard kernel is useless cause we need to rebuild the package if the guest additions will get fixes and/or VirtualBox itself will get upgraded by Oracle. So, I see no reason to provide even an own vbox package without a need to patch the official installer, but this was done for OSE, building for x86_64 is not so easy.

The lack of a large central Slackware repository is not a Salix specific problem, but one I think the Salix community shares with other Slackers.

You are free to contribute missed packages, as gapan has told you already. I am also a packager for Salix and have managed yet a bunch of packages took their way into repository. And gapan is a really nice boy teaching you and me the rules again and again.