@ruario
I only used AUR after noticing build failures and I was not finished after 5 minutes of effort!
This was mainly to keep Sumguys interest in slackware persistent and I guess to present that for the most part getting something "foreign" to work with slackware does not at all have to be a massive time sink.

I would never go to the point of saying such a method of configuring a build should be the norm! I'm sure a few of those patches were useless and/or there was a more elegant solution to get everything up and running.

@sumguy
I wrote the build script by looking at
https://aur.archlinux.org/packages/pi/pinball/PKGBUILD
and the patches were found https://aur.archlinux.org/packages/p...pinball.tar.gz

I think you and I think a lot alike!

When I was using Debian, the repositories were so huge, I could find anything I needed. Coming to Slackware, it's not that I'll be wanting to install all kinds of foreign programs- but just to know that that option is available to me on the rare occasion it is needed- and how to do it.

What you have shown me by example (by creating that custom Slackbuild for me) was invaluable! To be able to see first-hand how it is done; to have your work as a template; and to have it as something to reverse engineeer and use as a model, is truly the epitome of my Slackware experience thus far. I may not truly get a handle on Slackware package management until this winter, when I'll have time to sit in front of the computer and fool with it- but just showing me that it can be done...andhow it is done, indeed will ensure that I stay interested. [I must admit, for a while there, before you made me that Slackbuild, I was kind of thinking that I might be getting in over my head with Slackware. ]

Please don't misquote me. I never said it should be "the norm". I said,

The norm would just be to start with a basic SlackBuild template and work from there. However, if you are encountering difficulties, there is nothing wrong IMHO at looking at what other distros have done to help you along the way.

I have done this several times myself and I'm sure I'll do it again.

Just to be safe for all the new people in Slackware, if you see a tar.<anything> file, chances are it's a source package. Do NOT install it.

If you need a package for Slackware... go here: www.slackbuilds.org and find the package build script, run it, and install the package now located in /tmp. If one does not exist on SlackBuilds... ASK FIRST FOR ONE.

But installing from source is one of the great pleasures of *nix! Infidel!

And yeah I am just joking, I know what you are *trying* to say here, you cant install from source using the same tools as a binary package, but one of the great things about Slack is how often that just works exactly as it should. Yeah, making a big project with way too many branches (KDE or even GNOME for example) can be painful and time consuming, it makes sense to avoid that, but so often we are talking about relatively small simple programs that dont bring in multiple gigabytes of new dependencies and just havent been packaged. Configure; make; make install and done, why make it more complicated than that?

Because then, you won't get the benefits of Slackware's packages management system. A few examples:

• If the Makefile doesn't contain an uninstall target, of if you just deleted the source directory, how do you remove the application?
• How do you find from which source package comes a file that you installed with "make install"?
• How do you upgrade your application?

So, if you can't find a SlackBuild for this software, better write one yourself and use it to make a Slackware package IMO. You know that there are tools to help you make a Slackware packages from a source tarball, do you?

My own (personal) viewpoint:

Don't get me wrong. I am not anti manual installation of software and sometimes that requirement might be as simple as, "I know this piece of software won't do anything nuts (based on my past experience) and I'm willing to accept possible clean up. So I'll just manually install, rather than messing around with making a package."

I tend to always have a few bits of software outside of the Slackware packaging system, for reasons like that.

Even when I do manually install software, I always do some basic tracking at the very least.

1 members found this post helpful.

And you waited till today to let us know? Shame on you! (just kidding :-)

Well most Slackware users would be better off using slacktrack or src2pkg but this suits my own needs.

I also wrote my own very basic "package" creation script (it makes a tar with a self contained log).

Info from my old blog

Actually, I just remembered I have mentioned this kind of tracking on LQ before.

I disagree. The primary benefit of slackware's package management system, IMHOP, is the fact that unlike other package management systems it does NOT insist on owning everything and it's not so brittle that you have to change your way of working to avoid offending it. Redhat systems are a freaking nightmare, they dont care that you know what you are doing and it's really just fine, they throw a tantrum like a 4 year old hyped up on sugar and caffeine the minute you try to do something they havent approved, and Debian! I love Debian but the package management system is almost as brittle as RPM and even more of a tantrum-throwing control freak. Package management, in particular although among other things, always drives me back to Slack just because it will get out of the way and let me drive.

So I would say the exact opposite, if you do not install from source on occasion YOU are the one not getting the full benefit of the package system.

Upgrading is simple, you delete the old app and install the new version. Anything else, no matter how automagically delicious, is less than perfectly reliable, but if you are ok with that then you can just install the new app on top of the old one as well - that usually works fine.

Make uninstall is good practice so you should not delete the source directory (doh!) but even if you do it's not actually a big deal. Again, I would typically do this with a fairly small and uncomplicated application and therefore it's pretty easy to remember where I installed everything should I need to delete it later, but even if you delete the source directory and pay no attention whatsoever to where things went, and later really need to uninstall it, you can just download the source tarball again. Hardly rocket science.

@ruario I are apologies I guess I did but didn't want to attack you

Just wanted annouance my opinion. Which is arguably pure , you is collateral damage.

@Arkerless: I'm not sure I understand what you are claiming. I have had stuff outside of official packaging on variety of distros, with no problem. I don't see a massive advantage of the Slackware packaging system in this regard, as you are claiming

The one thing that would be easier on Slackware is to remove a system package and replace it with one installed by hand (since dependency tracking wouldn't get in your way) but I see no real reason for you to avoid packaging it, given that you would already have a SlackBuild anyway. Why wouldn't you just use the pre-provided SlackBuild and tweak it as needed?

On to your other point, unless you are tracking the install in some way, removal or upgrading a manually installed package is not always simple. For a small app with a single binary and man page and/or a reliable make uninstall target it is easy enough but for plenty of packages it is not straight forward.

You any others reading this should look at slacktrack (included with Slackware) or src2pkg. These are the sensible options for people exclusively using Slackware who don't have time, knowledge or energy to create a SlackBuild.

I should probably clarify that the reason I don't just use slacktrack and or sbopkg is that my work requires me to use multiple distros. Therefore, I created my own basic scripts instead. The advantage for me is that I can then use the same solution everywhere, with no real effort or setup. But I still keep track of all newly created files. Unless you don't care about your system becoming a mess of files you can't keep track of, I would suggest others also use some system to keep track of applications installed on their system. More often than not the simplest way will be to make a native package.

1 members found this post helpful.