LinuxQuestions.org
Share your knowledge at the LQ Wiki.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices

Reply
 
Search this Thread
Old 02-03-2009, 09:10 PM   #16
salemboot
Member
 
Registered: Mar 2007
Location: America
Distribution: Linux
Posts: 159

Rep: Reputation: 36

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.

Last edited by salemboot; 02-03-2009 at 09:11 PM.
 
Old 02-04-2009, 12:46 AM   #17
OverlordManny
LQ Newbie
 
Registered: Jun 2004
Location: Louisiana, United States
Distribution: Ubuntu, Solaris, but currently I'm loving Slackware.
Posts: 12

Original Poster
Rep: Reputation: 1
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!
 
Old 02-04-2009, 12:51 AM   #18
OverlordManny
LQ Newbie
 
Registered: Jun 2004
Location: Louisiana, United States
Distribution: Ubuntu, Solaris, but currently I'm loving Slackware.
Posts: 12

Original Poster
Rep: Reputation: 1
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.

Last edited by OverlordManny; 02-04-2009 at 01:04 AM.
 
Old 02-04-2009, 02:22 AM   #19
geek745
Member
 
Registered: Jul 2004
Location: Boston, MA
Distribution: Slackware; Ubuntu; Slax
Posts: 172
Blog Entries: 2

Rep: Reputation: 33
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.
 
Old 02-04-2009, 03:39 AM   #20
titopoquito
Senior Member
 
Registered: Jul 2004
Location: Ruhr Area, Germany
Distribution: Slackware64 14.0
Posts: 1,517

Rep: Reputation: 90
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.
 
Old 02-04-2009, 06:00 AM   #21
skuzye
Member
 
Registered: Jul 2008
Location: São Paulo - Brazil
Distribution: Fedora 17
Posts: 97

Rep: Reputation: 15
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
 
Old 02-04-2009, 10:41 AM   #22
gnashley
Amigo developer
 
Registered: Dec 2003
Location: Germany
Distribution: Slackware
Posts: 4,749

Rep: Reputation: 461Reputation: 461Reputation: 461Reputation: 461Reputation: 461
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.
 
Old 02-04-2009, 03:26 PM   #23
rworkman
Slackware Contributor
 
Registered: Oct 2004
Location: Tuscaloosa, Alabama (USA)
Distribution: Slackware
Posts: 1,912

Rep: Reputation: Disabled
Quote:
Originally Posted by salemboot View Post
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.
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.

Quote:
Like 'freetype' should have all the sub-pixel hinting algorithms enabled. But they aren't.
They are not, and they shouldn't be. Slackware is based in the USA, and thus it must comply with laws of the USA.

Quote:
* If you are going to provide a service make sure to include everything in the build.
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.

Quote:
I've yet to see a i386-tar.gz for NetworkManager / KNetworkManager or a SlackBuild
NetworkManager's recent releases won't build on a Slackware system without *major* changes to the system as a whole.
 
Old 02-04-2009, 08:39 PM   #24
onebuck
Moderator
 
Registered: Jan 2005
Location: Midwest USA, Central Illinois
Distribution: Slackware®
Posts: 11,044
Blog Entries: 1

Rep: Reputation: 1369Reputation: 1369Reputation: 1369Reputation: 1369Reputation: 1369Reputation: 1369Reputation: 1369Reputation: 1369Reputation: 1369Reputation: 1369
Hi,
Quote:
Originally Posted by salemboot View Post
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.
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.
 
Old 02-04-2009, 09:53 PM   #25
salemboot
Member
 
Registered: Mar 2007
Location: America
Distribution: Linux
Posts: 159

Rep: Reputation: 36
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.

Last edited by salemboot; 02-04-2009 at 09:58 PM.
 
Old 02-04-2009, 11:01 PM   #26
lordwolf
Member
 
Registered: May 2007
Distribution: Slackware
Posts: 44

Rep: Reputation: 15
Quote:
Originally Posted by salemboot View Post
I am merely stating the obvious.
...
Put a statement somewhere letting the user know their software is crippled.
...
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

Then again, this is only my personal opinion. I just thought I had to post this when I see your reply.
 
Old 02-05-2009, 12:54 AM   #27
mRgOBLIN
Slackware Contributor
 
Registered: Jun 2002
Location: New Zealand
Distribution: Slackware
Posts: 999

Rep: Reputation: 226Reputation: 226Reputation: 226
Quote:
Originally Posted by salemboot View Post

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.'

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!'
 
Old 02-05-2009, 02:17 AM   #28
H_TeXMeX_H
Guru
 
Registered: Oct 2005
Location: $RANDOM
Distribution: slackware64
Posts: 12,928
Blog Entries: 2

Rep: Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269
Quote:
Originally Posted by salemboot View Post
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.'

...

I have my opinion and you still have yours.
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.
 
Old 02-05-2009, 04:55 AM   #29
skuzye
Member
 
Registered: Jul 2008
Location: São Paulo - Brazil
Distribution: Fedora 17
Posts: 97

Rep: Reputation: 15
Quote:
Originally Posted by salemboot View Post
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.

Maybe you should ask for your money back
 
Old 02-05-2009, 05:25 AM   #30
onebuck
Moderator
 
Registered: Jan 2005
Location: Midwest USA, Central Illinois
Distribution: Slackware®
Posts: 11,044
Blog Entries: 1

Rep: Reputation: 1369Reputation: 1369Reputation: 1369Reputation: 1369Reputation: 1369Reputation: 1369Reputation: 1369Reputation: 1369Reputation: 1369Reputation: 1369
Hi,
Quote:
Originally Posted by salemboot View Post
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.
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.
 
  


Reply

Tags
app, dependency, lib, package, slackbuild, slackware


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Ubuntu as frugal install, iso install, img install? impossible? nooby Ubuntu 15 08-22-2008 05:49 AM
Red Hat Linux 9 install: error "No devices found to install ... gunneszz Red Hat 1 03-10-2008 04:52 AM
apt-get install dependency problems with hplip software and kde install for Agnula maybi7 Linux - Software 1 02-03-2007 05:16 PM
How do I re-install an operatingsystem? Corrupted install. Yast wont load. URGENT.thx CrewXp Suse/Novell 5 05-09-2005 12:07 AM
calling all networking gurus (nfs install) N_A_J_M Linux - Networking 0 12-15-2002 06:13 PM


All times are GMT -5. The time now is 03:14 PM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration