checkinstall works great.

One problem I noticed about Slackbuilds.org, take a look at their 'ffmpeg' SlackBuild.
It's missing some options. This is a problem on the Debian side of things to.
They don't enable everything. Not that you need it, but some people just like to have everything enabled. Like 'freetype' should have all the sub-pixel hinting algorithms enabled. But they aren't.

* If you are going to provide a service make sure to include everything in the build.

libdvdcss may as well be illegal in the U.S. But you can still get it and compile it yourself. Which in the end you'll be doing for VLC.

MPlayer is another one that has several options and dependencies, such as, XVID, lame, libdvdcss, libdvdread... If you want to play newer DVD releases you'll be retrieving cvs/svn's. dvdnav is a pain to build as well.

I've yet to see a i386-tar.gz for NetworkManager / KNetworkManager or a SlackBuild.

I haven't looked all that hard but, hey.

I'm rambling on.

Well I just did a clean install of slack 12.2 mainly because I want to set it all up again for the experience and the fun(my home folder is on another partition so what do I really have to loose) . I'm a tweaker by nature and I'm one that can't always just leave well enough alone. I decided this time to not install the KDE packages, I don't use KDE and don't care for it. The one downfall is that I DO use amarok. Seeing as this is an adventure for me I've decided to compile Amarok 2.0.1.1 and make slackpackages for my own use. I'm sure they are probably available but i want the fun and pride of rolling my own. I've got qt4 building ATM and have the other deps downloaded. Yay for slack!

Another tid bit from me... I have to say thanks to Pat V. You've made such a great distro. I have in the past dreaded compiling due to continuous and ambiguous errors due to lack of libs on other distros. Compiling in Slackware is like butter. I feel like a bird that's just finally gotten his wings.

One suggestion I haven't heard here yet is drawing your own dependency diagram to document your travels through "dependency resolution" (let's not call it hell since we embrace it so dearly). My personal favorite is the GTK with glib, pango, cairo, freetype and a plethora of other tools - to build the GIMP is not too bad - add Inkscape or Pidgin with their gtkmm/glibmm dependencies and you end up with an amazing tree, fortunately documented on the gtkmm website: http://www.gtkmm.org/jhbuild_dot_gtkmm.png - something similiar for your own use will help you out when you (inevitably) go to compile the next version.

For convenience it's easier to build them on your main system, so that many dependencies are picked up that you have build and installed before (thinking for example of ffmpeg and exiv2, which are required by several applications).

But you can of course also compile your packages in a virtual machine that is easily revertible to the stock Slackware install. This way you can examine what packages are really needed, it will not automatically pick all fancy stuff you have installed before. Inspecting dependencies is much easier that way I think. This might come handy too if you don't want a program to be linked against another one.

Just to add something here as no one said it specifically. pkg-tool exists for one simple reason: keep you're system organized. So use it, it doesn't hurt and it's not difficult once you get it.

I explain: suppose you start installing dependencies and two different software needs the same dependencies but one package need a different version. You use make, make install and if you don't take care enough you end up with a mix of versions. Say goodbye to your rock stable slackware system, this different software may crash eventually.

Now suppose you want to remove one of these software and it doesn't have a make uninstall... how would you do it? Suppose even that you need to remove one version of the dependency and it removes files from the other... or suppose you want to upgrade you're system to the newer version without reinstalling it... or suppose you want to restore it to the a clean installation...

Skuzye

If you use src2pkg to create packages it can produce slack-required files for you (like those used by slapt-get) which provide pretty good information about which other packages are needed by the package. Even if you don't use slapt-get, the information is pretty handy. If there are *build-time* dependencies these can't be detected, but you can manually add them to the slack-required. It makes a pretty good way to keep concise notes about what is needed for any package. In contrast to other tools which produce slack-required files, src2pkg will list each individual library needed by the package, as well as the package names they are contained in.

Some people think they'd like to have all the newest versions of all the software too, but like everything else, there's this concept of costs versus benefits that rears its ugly head. If the cost of "enable everything" (whether that cost comes in the form of increased time required to figure out deps, lots more required packages for deps, incompatibilities with other packages, or whatever) is greater than the perceived benefits of "enable everything," then the choice is obvious.

They are not, and they shouldn't be. Slackware is based in the USA, and thus it must comply with laws of the USA.

If I am going to provide a service, then I'll provide it however I damn well please, and then you and everyone else can decide whether you like it that way. If not, then you're free to use another service. More importantly, in ALL of the above cases, the source and build scripts are freely available and modifiable - you are free to make the necessary changes. Even better, if those necessary changes don't put the cost versus benefits relationship out of balance, you can send those changes to the maintainers and perhaps get them included, therein making the service provided more acceptable to you.

NetworkManager's recent releases won't build on a Slackware system without *major* changes to the system as a whole.

Hi,
Actually the people behind Slackbuilds provide a great service to the Slackware community. What have you provided other than criticism?

Maybe you should research a little more to setup the scripts as you like, that way you will have things setup the way you like it.

I am merely stating the obvious.

So let the travelers know what perils lie ahead.

Put a statement somewhere letting the user know their software is crippled.

Then notate it in the SlackBuild.

Good documentation is normal practice for a software developer.

Good rule of thumb, 'if you don't have the time then don't release the product of your efforts.'

Example of notation,

#Options disabled for export law, dcma, and other violations
UNSAFE_OPTIONS=" --enable-ta --enable-hai --enable-wa "

configure --prefix=/tmp/build --enable-ni --enable-hao \
#$UNSAFE_OPTIONS \
--enable-na &> log &
tail log

...


I have my opinion and you still have yours.

Aren't you being a little out of line here? What do you mean by crippled software? If you're talking about the build scripts, I've used many slackbuilds from slackbuilds.org without having to modify anything - including mplayer and ffmpeg. They work just fine. Besides, like what have been pointed out to you, you can always modify them in any way you want to fit your needs.

By the way, I thought slackbuilds.org is providing slackbuild scripts, not service. If you want service, you'll have to pay for it! Isn't that what open source is all about? ;) But, of course, you can always ask for advice here on LQ :D

Then again, this is only my personal opinion. I just thought I had to post this when I see your reply.

Your attitude makes me angry.

Good rule of thumb, 'You have every right to an opinion and you have every right to make suggestions. You have absolutely no right to make demands!'

So, you're basically saying that Slackbuilds = crippled software, therefore we should add a statement to them saying "Note: this software is crippled (salemboot says so)."

You know what I think. I think if you have a problem with a certain Slackbuild, submit a new one, make sure to follow your motto

'if you don't have the time then don't release the product of your efforts.'

then submit it. If it's good enough I'm sure it will be approved. Then we will no longer have to add that silly note.

Maybe you should ask for your money back ;)

Hi,
Yes, I have my opinion as do you have yours! Thankfully mine is better than yours. :) As for the crippling thing, that is your opinion sticking it's head up again.

Slackbuild and Slackware are two independent entities. The people at Slackbuilds provide a great venue not a service. Sure Slackware could exist without Slackbuilds but it's nice to have the scripts available to the public to build packages. I personally don't use Slackbuilds that much but I know it's there if I should need something and I don't want to spend a lot of time to build that GNU/Something.

As for applying your 'rules of thumb' to Slackbuilds. There is nothing stopping you from doing that, write and submit. You cannot expect someone to cover all aspects for a system unless you specify the requirements before hand.

Yes, good documentation is important with anything that has interaction. You could start any day, I'm sure that Slackbuilds would like good technical writing support but I like the 'KISS' principle that they seem to adhere too.