LinuxQuestions.org
Visit the LQ Articles and Editorials section
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 07-17-2013, 07:45 AM   #16
Pearson
LQ Newbie
 
Registered: Jul 2013
Posts: 9

Original Poster
Rep: Reputation: Disabled

Quote:
Originally Posted by solarfields View Post
Pearson,

If you install your third party software from http://slackbuilds.org/ you can use sbotools to automate the installation process from there. You can install it from SBo. Another approach, as camorri mentioned above is to use sbopkg in combination with build queues. There is a script called sqg that can generate a build queue automatically for any entry from SBo (as long as it is the 14.0 repository) or can generate build queues for everything in the repo.

Now, generating a single queue file, for example for QtiPlot is as simple as:

sqg -p QtiPlot

While generating all queue files is done by:

sqg -a

After that you can easily navigate and load the queues you need in sbopkg.

Hope this helps.
Very interesting. I'll have to read more about this. The sbo stuff is new to me.
 
Old 07-17-2013, 07:55 AM   #17
Pearson
LQ Newbie
 
Registered: Jul 2013
Posts: 9

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by Didier Spaier View Post
If you don't want to worry about dependencies, just make a full install. I realize that's not the answer you expected, but I have yet to find any practical inconvenience of what you call "system bloat", provided you have enough space on disk.
The more I think about it, I may have been on dialup the last time I used Slackware. So, the more packages I had installed, updates took that much longer. That should be less of an issue now.

Quote:
Originally Posted by Didier Spaier View Post
If you installed a program but don't use it, it won't slow down your system, not will it put it at risk.
I'll have to reread the Installation notes, but wouldn't a full install have more running than I will likely need? For example (and this may not be exactly true) would a full install leave me with a running postgres server and web server? I don't intend to run those.

As for "nor will it put it at risk", I've been doing some security related stuff at work. We've been following the philosophy of "minimizing attack vectors" -- the more software you have running, the more opportunities for problems. Having something extra installed doesn't bother me as much as having things running that I don't need.
 
Old 07-17-2013, 08:05 AM   #18
ruario
Senior Member
 
Registered: Jan 2011
Location: Oslo, Norway
Distribution: Slackware
Posts: 1,817

Rep: Reputation: 817Reputation: 817Reputation: 817Reputation: 817Reputation: 817Reputation: 817Reputation: 817
services are not enabled just because they are installed, like on other distros. so no, slack will not be slower just because you have more things installed.

as for updates. slack only updates packages in stable if they are critically needed. so even with a full install you will likely get far less updates than a slimmer install of most other distros.

you might find this interesting:

http://my.opera.com/ruario/blog/2011...ncy-management
 
3 members found this post helpful.
Old 07-17-2013, 08:25 AM   #19
Didier Spaier
Senior Member
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slackware{,64}-{14.1,current} on a Lenovo Thinkpad T61 6457-4XG
Posts: 4,177

Rep: Reputation: 1018Reputation: 1018Reputation: 1018Reputation: 1018Reputation: 1018Reputation: 1018Reputation: 1018Reputation: 1018
Quote:
Originally Posted by Pearson View Post
The more I think about it, I may have been on dialup the last time I used Slackware. So, the more packages I had installed, updates took that much longer. That should be less of an issue now.
Especially now as Slackware have begun to ship ESR versions of Firefox (which is a wise move IMHO), so update of it should become less frequent.

Quote:
Originally Posted by Pearson View Post
I'll have to reread the Installation notes, but wouldn't a full install have more running than I will likely need? For example (and this may not be exactly true) would a full install leave me with a running postgres server and web server? I don't intend to run those.
During installation you are requested to tell which services (mostly daemons) you want to start at boot time (or not).

And forbidding a web or database or other service to start at boot time after installation is just a "chmod -x /etc/rc.d.rc.<service name>'' away.

Oh and for the sake of accuracy, postgres is not shipped in Slackware, and /etc/rc.d/rc.httpd and /etc/rc.d/c.mysqld are not executable by default.

Personally I just disable rc.sshd and rc.inetd among the ones proposed to be "on" by default, as this is for a laptop.

Quote:
Originally Posted by Pearson View Post
As for "nor will it put it at risk", I've been doing some security related stuff at work. We've been following the philosophy of "minimizing attack vectors" -- the more software you have running, the more opportunities for problems. Having something extra installed doesn't bother me as much as having things running that I don't need.
Yeah, so just review all scripts in /etc/rc.d and make non executable those you don't want to run.

Last edited by Didier Spaier; 07-17-2013 at 09:06 AM. Reason: No mouse clicks during installation...
 
2 members found this post helpful.
Old 07-17-2013, 08:28 AM   #20
cwizardone
Senior Member
 
Registered: Feb 2007
Distribution: Slackware64-current & "True Multilib." PC-BSD.
Posts: 2,233

Rep: Reputation: 176Reputation: 176
Quote:
Originally Posted by ruario View Post
...you might find this interesting:

http://my.opera.com/ruario/blog/2011...ncy-management
Very well done!
Thanks.
 
Old 07-17-2013, 09:12 AM   #21
Pearson
LQ Newbie
 
Registered: Jul 2013
Posts: 9

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by ruario View Post
as for updates. slack only updates packages in stable if they are critically needed. so even with a full install you will likely get far less updates than a slimmer install of most other distros.
This reminds me -- I wanted to look at how Slackware handles security fixes (i.e. CVEs). Thanks for the reminder.

Quote:
Originally Posted by ruario View Post
When I said I'd accept an "RTFM" as long as someone pointed me to the manual, this is what I had in mind. Thanks for the link. This (or something like it) should be on the "Must Read" list of new Slackware users.
 
Old 07-17-2013, 09:15 AM   #22
Pearson
LQ Newbie
 
Registered: Jul 2013
Posts: 9

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by Didier Spaier View Post
During installation you are requested to tell which services (mostly daemons) you want to start at boot time (or not).

And forbidding a web or database or other service to start at boot time after installation is just a "chmod -x /etc/rc.d.rc.<service name>'' away.
[...]
Personally I just disable rc.sshd and rc.inetd among the ones proposed to be "on" by default, as this is for a laptop.

Yeah, so just review all scripts in /etc/rc.d and make non executable those you don't want to run.
Cool, more of my questions/concerns are answered.

You guys (and gals?) are great!
 
Old 07-17-2013, 09:40 AM   #23
jtsn
Member
 
Registered: Sep 2011
Location: Europe
Distribution: Slackware
Posts: 803

Rep: Reputation: 354Reputation: 354Reputation: 354Reputation: 354
Quote:
Originally Posted by elesmod View Post
You could manually log the packages and their dependencies that you install using sbopkg.

Let's say I'm installing a program from slackbuilds.org named "oranges", in the info file there are listed dependencies: "bananas" and "grapes". Upon checking the info files of the 2 dependencies, I find that "grapes" also needs "libwatermelons"

So, into my "installed_packages.txt" I type:
[...]
The main issue with Linux application software is not how you track dependencies. It is that you have to track them, even if you don't want to. It may even be the main reason, why Linux fails so hard on the desktop.

Ingo Molnar wrote a insightful article on the topic: https://plus.google.com/109922199462...ts/HgdeFDfRzNe
 
1 members found this post helpful.
Old 07-17-2013, 01:36 PM   #24
BCarey
Senior Member
 
Registered: Oct 2005
Location: New Mexico
Distribution: Slackware
Posts: 1,455

Rep: Reputation: Disabled
Quote:
Originally Posted by TobiSGD View Post
If more than one package contains a specific file removepkg by default will not delete that file if you remove one of the packages, but will remove it once you remove the last package that contains that specific file.
My bad, I misread the statement as referring to packages rather than files.

Brian
 
Old 07-17-2013, 01:57 PM   #25
TobiSGD
Moderator
 
Registered: Dec 2009
Location: Hanover, Germany
Distribution: Main: Gentoo Others: What fits the task
Posts: 15,560
Blog Entries: 2

Rep: Reputation: 4035Reputation: 4035Reputation: 4035Reputation: 4035Reputation: 4035Reputation: 4035Reputation: 4035Reputation: 4035Reputation: 4035Reputation: 4035Reputation: 4035
Quote:
Originally Posted by Pearson View Post
For simplicity, would it make sense to copy the info file for all packages I install (via sbopkg)? Then I could grep those info files, and there's less copy/paste (chance for error!) involved.
If you go for this approach you might want to copy the README files also, since you possibly have installed a package with an optional dependency. Those are not mentioned in the info files.
 
Old 07-17-2013, 03:17 PM   #26
thirdm
Member
 
Registered: May 2013
Location: Massachusetts
Distribution: Slackware,OpenBSD
Posts: 54

Rep: Reputation: Disabled
Quote:
Originally Posted by jtsn View Post
The main issue with Linux application software is not how you track dependencies. It is that you have to track them, even if you don't want to. It may even be the main reason, why Linux fails so hard on the desktop.

Ingo Molnar wrote a insightful article on the topic: https://plus.google.com/109922199462...ts/HgdeFDfRzNe
I'm having trouble understanding both this article and the argument.
To me, Paul-Henning Kamp characterizes the problem (or what I think of as the problem) more clearly and convincingly here: https://queue.acm.org/detail.cfm?id=2349257
The answer long term, IMO, is to go back to the source of the good things in UNIX for what they've decided was wrong with it, starting fresh on top of plan 9 while at the same time ignoring Mac OS, Windows, and mobile device design choices (thus avoiding the difficult design point of having to try to be all things to all people).
 
Old 07-17-2013, 04:06 PM   #27
volkerdi
Slackware Maintainer
 
Registered: Dec 2002
Location: Minnesota
Distribution: Slackware! :-)
Posts: 861

Rep: Reputation: 1684Reputation: 1684Reputation: 1684Reputation: 1684Reputation: 1684Reputation: 1684Reputation: 1684Reputation: 1684Reputation: 1684Reputation: 1684Reputation: 1684
IMHO, it's better to use "readelf -d" to check for library dependencies than it is to use "ldd". That way you only see which libraries are directly linked with the binary (and not all the libraries linked to those libraries, etc.)

Using ldd can leave you thinking that there's a lot more stuff to rebuild after an soname bump than there actually is.
 
5 members found this post helpful.
Old 07-17-2013, 04:23 PM   #28
astrogeek
Senior Member
 
Registered: Oct 2008
Distribution: Slackware: 12.1, 13.1, 14.1, 64-14.1, -current, FreeBSD-10
Posts: 1,769

Rep: Reputation: 601Reputation: 601Reputation: 601Reputation: 601Reputation: 601Reputation: 601
Quote:
Originally Posted by jtsn View Post
The main issue with Linux application software is not how you track dependencies. It is that you have to track them, even if you don't want to. It may even be the main reason, why Linux fails so hard on the desktop.

Ingo Molnar wrote a insightful article on the topic: https://plus.google.com/109922199462...ts/HgdeFDfRzNe
Hmmm... I expected more, but I find the article neither insightful nor particularly applicable to actual 'package management', but rather totally focused on the app marketplace point of view - marketspeak.

He states...

Quote:
(Yes, we all heard of the cases where Apple or Google banned an app. Don't listen to what they say but see what they do: there's literally hundreds of thousands of apps on both of the big app markets - they are, for all practical purposes, free marketplaces from the user's point of view.)
But that is neither good enough nor sincere. Freedom "for all practical purposes" or "from the user's point of view" is not freedom at all... but that at this point we are straying far from the topic of package management.
 
Old 07-17-2013, 06:57 PM   #29
jtsn
Member
 
Registered: Sep 2011
Location: Europe
Distribution: Slackware
Posts: 803

Rep: Reputation: 354Reputation: 354Reputation: 354Reputation: 354
Quote:
Originally Posted by thirdm View Post
I'm having trouble understanding both this article and the argument.
Molnar discusses why people actually use operating systems: to run applications of their own choice. Most mainstream Linux distributions make that especially hard. They either try to choose applications for you or try to provide distro-modified versions of everything in existence on their own (and then end in the dependency hell).

Upstream is at fault too. Most FOSS developers provide OOtB Windows and Mac Binaries. When you ask for a Linux version, they send you to your Linux distributor, provide their own Linux (live) distribution or throw source tarballs at you. (Mozilla is an exception, they actually provide a working self-contained binaries of Firefox.)

For Linux success on the desktop, that has to change immediately. If someone wants to try out a new KDE version, it has to work this way:

1. Go to KDE.org
2. Choose your Platform (Linux, x86, x86-64 etc.)
3. Download the KDE installer
4. Run it to install KDE into /opt or $HOME on every major Linux distribution without interfering anything.

If you're on Windows, it actually works this way: http://windows.kde.org/ (which is sad for FOSS)

If you're on Linux, they send you there: http://techbase.kde.org/Getting_Started/Build/KDE4

And there the journey of the desktop end-user abruptly ends...

Quote:
Originally Posted by astrogeek
Hmmm... I expected more, but I find the article neither insightful nor particularly applicable to actual 'package management',
Did you read Part II?

https://plus.google.com/109922199462...ts/VSdDJnscewS
 
Old 07-17-2013, 07:14 PM   #30
TobiSGD
Moderator
 
Registered: Dec 2009
Location: Hanover, Germany
Distribution: Main: Gentoo Others: What fits the task
Posts: 15,560
Blog Entries: 2

Rep: Reputation: 4035Reputation: 4035Reputation: 4035Reputation: 4035Reputation: 4035Reputation: 4035Reputation: 4035Reputation: 4035Reputation: 4035Reputation: 4035Reputation: 4035
Quote:
Originally Posted by jtsn View Post
For Linux success on the desktop, that has to change immediately. If someone wants to try out a new KDE version, it has to work this way:

1. Go to KDE.org
2. Choose your Platform (Linux, x86, x86-64 etc.)
3. Download the KDE installer
4. Run it to install KDE into /opt or $HOME on every major Linux distribution without interfering anything.

If you're on Windows, it actually works this way: http://windows.kde.org/ (which is sad for FOSS)
If you watch the "average Windows user" you will recognize that this is exactly not the way it works. It rather works this way:
If someone wants to use a new version of a software (which actually rarely happens, most people never update unless a dialog asks them to) he does this:
1. Go to Google, search for the software.
2. Click on whatever link Google spits out first, irrelevant how shady that site is.
3. Download that binary without ever thinking about things like signed software packages and checksums.
4. Start the installer, give it admin privileges and click next as often as you can, without reading what is written on the screen or thinking about the implications of giving some random software admin privileges.

Having repositories has an advantage that you will see very rarely on Windows machines: A trusted software source. Not having repositories is a serious disadvantage for the average user and everyone who maintains Windows systems from those average users knows that.
Funnily, things like app-stores on Android and iOS devices teach people the simplicity of this approach without giving them the real advantages, because the apps are not really tested (why should they care anyways, more sold apps mean more profit for Apple/Google, you can delete them from the store if someone reports the malware).
 
4 members found this post helpful.
  


Reply


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
[SOLVED] Sanity check LFS 7.0 - do I need to re-add packages in GCC pass 2? DrinkinHomeBrew Linux From Scratch 2 12-19-2011 10:23 AM
Installing/deinstalling packages under Ubuntu & handling boot problems with Grub ... rakeshj Linux - Software 2 07-15-2007 02:27 PM
Packages & Installing software Spamdrew Slackware 4 07-03-2006 10:36 AM
Updating custom packages - best practices dunric Slackware 1 01-10-2006 07:36 AM
best practices for subprocs & pipes in python bardinjw Programming 0 11-28-2005 12:27 PM


All times are GMT -5. The time now is 10:35 AM.

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