LinuxQuestions.org
Help answer threads with 0 replies.
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-18-2011, 10:17 PM   #1096
slakmagik
Senior Member
 
Registered: Feb 2003
Distribution: Slackware
Posts: 4,113

Rep: Reputation: Disabled

55020++

That post is worth putting in a frame on the wall.
 
1 members found this post helpful.
Old 02-18-2011, 10:44 PM   #1097
chrisretusn
Member
 
Registered: Dec 2005
Location: Philippines
Distribution: Slackware
Posts: 508

Rep: Reputation: Disabled
Quote:
Originally Posted by Robert.Thompson View Post
The option to automatically check for and install dependencies.
Responses so far as expected.

I will add myself as one of those who disagrees. Slackware's not checking dependencies is one of the many reasons I use Slackware. Every time I install an application from a repository on one of my kid's laptops (non-Slackware) I am often amazed at all of the stuff (dependencies) installed along with it. It always seems to be a all or nothing approach that I have no control over. I am at the mercy of the packagers. I just don't like that.

I build most of my own non-Slackware packages. Often there are optional dependencies I do not want in my builds. Even with SlackBuild.org I find my self modifying builds to remove or add features because the authors, maintainers often also follow that all or nothing approach. I least I have the option to roll my own.

I want absolute control of dependencies. That control is lost when automatic dependency checking is implemented. There is no way that dependency checking can cover all bases. Even if optional, it still adds more complexity to what we already have for program updating. To be perfectly blunt, if you want dependency checking there are nonstandard-Slackware options already available, there are other distributions too.
 
Old 02-18-2011, 11:00 PM   #1098
D1ver
Member
 
Registered: Jan 2010
Distribution: Slackware 13.37
Posts: 527
Blog Entries: 3

Rep: Reputation: 126Reputation: 126
For the most part I really like how Slackware handles package management. I find it simple and effective for the vast majority of applications.

The only trouble I have had came from trying to install Mumble. Something that would have taken 5 minutes in the mainstream distros ended up taking me hours and hours. Thankfully this forum community is amazingly helpful and a very nice person held my hand through the entire dependency hell.
 
Old 02-18-2011, 11:14 PM   #1099
hitest
Senior Member
 
Registered: Mar 2004
Location: Prince Rupert, B.C., Canada
Distribution: Slackware, OpenBSD
Posts: 4,276

Rep: Reputation: 587Reputation: 587Reputation: 587Reputation: 587Reputation: 587Reputation: 587
Smile

Quote:
Originally Posted by sycamorex View Post
While I totally agree with you and do NOT see the need for automatic dependency checking I think Robert highlighted the word 'option' for a reason. Perhaps, some weird people would like such capability. On the one hand, such an OPTION would let Slackware accommodate the needs of a wider range of users, on the other hand, it'd create an unnecessary layer of complexity, which we don't like, do we?
Sure, I suppose PV could add in a dependency checking system as an option, but, the resulting distro would no longer be Slackware as I know it. As I understand it if Slackware ever does add dependency checking that is a sure sign of the Apocalypse.
 
1 members found this post helpful.
Old 02-19-2011, 08:02 AM   #1100
GazL
Senior Member
 
Registered: May 2008
Posts: 3,502

Rep: Reputation: 1024Reputation: 1024Reputation: 1024Reputation: 1024Reputation: 1024Reputation: 1024Reputation: 1024Reputation: 1024
Quote:
Originally Posted by slakmagik View Post
55020++

That post is worth putting in a frame on the wall.
Couldn't agree more.
 
1 members found this post helpful.
Old 02-19-2011, 08:07 AM   #1101
Nylex
LQ Addict
 
Registered: Jul 2003
Location: London, UK
Distribution: Slackware
Posts: 7,464

Rep: Reputation: Disabled
It would be nice to have another login manager, besides XDM and KDM.
 
Old 02-19-2011, 10:53 AM   #1102
AlvaroG
Member
 
Registered: Jul 2009
Location: Canelones, Uruguay
Distribution: Slackware
Posts: 128

Rep: Reputation: 31
Quote:
Originally Posted by 55020 View Post
Bad idea. Everything that is optional for the *user*, is compulsory for the *maintainer*.
While I understand this sentence, and the explanation you gave after this, there is one simple reply to it: you are already doing this work each time you write "this package depends on program a, b, c, and d, and optionally on e and f" in the SlackBuild description. So I don't see how bad it could be to give that information a standard format that sbopkg can understand and use to build a queue. Or not, because it is *optional*
Don't get me wrong, I dislike automatically and mandatory dependency checking as much as you do.


Regards.
 
Old 02-19-2011, 12:28 PM   #1103
hitest
Senior Member
 
Registered: Mar 2004
Location: Prince Rupert, B.C., Canada
Distribution: Slackware, OpenBSD
Posts: 4,276

Rep: Reputation: 587Reputation: 587Reputation: 587Reputation: 587Reputation: 587Reputation: 587
There are many distros out there that have that dependency checking. When dependency checking works it is a wonderful thing. But, from my experience dependency checking can and will fail. When it does fail you're left to gnash your teeth and resolve said dependency issues manually.
Slackware avoids this pitfall entirely. Suffice it to say that I am thrilled with Slackware's security, stability, and speed. If the option of dependency checking is included in Slackware then our distro will be less stable, secure, and speedy.
I wholeheartedly vote NO to dependency checking.
By the way, my rant is not intended to be a criticism of you, Robert, but, rather an endorsement of what works the best for Slackware (my opinion).

Last edited by hitest; 02-19-2011 at 12:30 PM.
 
Old 02-19-2011, 12:42 PM   #1104
Darth Vader
Member
 
Registered: May 2008
Location: Romania
Distribution: DARKSTAR Linux 2008.1
Posts: 659

Rep: Reputation: 138Reputation: 138
Technically, if you have one package dependencies unresolved, your (forced) package installation will gracious crash. In fact, the dependencies management works for you.
 
Old 02-19-2011, 01:37 PM   #1105
Darth Vader
Member
 
Registered: May 2008
Location: Romania
Distribution: DARKSTAR Linux 2008.1
Posts: 659

Rep: Reputation: 138Reputation: 138
Also, if we like or not, the Slackware packages have dependencies, like any Linux operating system. We can install them in a manual mode, or we can use an automatically mode. For the curious, here we go:

Code:
PACKAGE NAME:  ConsoleKit-20100129-i486-1.txz
PACKAGE MIRROR: http://slackware.cs.utah.edu/pub/slackware/slackware-13.1/
PACKAGE LOCATION:  ./slackware/l
PACKAGE SIZE (compressed):  92 K
PACKAGE SIZE (uncompressed):  460 K
PACKAGE REQUIRED:  dbus,dbus-glib,eggdbus,glib2,glibc-solibs,libX11,libXau,libXdmcp,libxcb,polkit,zlib
PACKAGE CONFLICTS: 
PACKAGE SUGGESTS: 
PACKAGE DESCRIPTION:
ConsoleKit: ConsoleKit (user, login, and seat tracking framework)
ConsoleKit:
ConsoleKit: ConsoleKit is a framework for defining and tracking users, login
ConsoleKit: sessions, and seats.
ConsoleKit:
ConsoleKit: Homepage: http://freedesktop.org/wiki/Software/ConsoleKit
ConsoleKit:

PACKAGE NAME:  M2Crypto-0.19.1-i486-2.txz
PACKAGE MIRROR: http://slackware.cs.utah.edu/pub/slackware/slackware-13.1/
PACKAGE LOCATION:  ./slackware/l
PACKAGE SIZE (compressed):  192 K
PACKAGE SIZE (uncompressed):  1090 K
PACKAGE REQUIRED:  glibc-solibs,openssl | openssl-solibs,python
PACKAGE CONFLICTS: 
PACKAGE SUGGESTS: 
PACKAGE DESCRIPTION:
M2Crypto: M2Crypto (cryptography toolkit for Python)
M2Crypto:
M2Crypto: M2Crypto is a crypto and SSL toolkit for Python.  It includes:
M2Crypto: - RSA, DSA, DH, HMACs, message digests, symmetric ciphers (e.g. AES)
M2Crypto: - SSL functionality to implement clients and servers
M2Crypto: - HTTPS extensions to Python's httplib, urllib, and xmlrpclib
M2Crypto: - Unforgeable HMAC'ing AuthCookies for web session management
M2Crypto: - FTP/TLS client and server, S/MIME v2, ZServerSSL, ZSmime
M2Crypto:
M2Crypto: Website: http://wiki.osafoundation.org/bin/view/Projects/MeTooCrypto
M2Crypto:

PACKAGE NAME:  MPlayer-20100218-i486-1.txz
PACKAGE MIRROR: http://slackware.cs.utah.edu/pub/slackware/slackware-13.1/
PACKAGE LOCATION:  ./slackware/xap
PACKAGE SIZE (compressed):  8108 K
PACKAGE SIZE (uncompressed):  25160 K
PACKAGE REQUIRED:  aalib,alsa-lib,atk,attr,audiofile,bzip2,cairo,cdparanoia,cxxlibs | gcc-g++,cyrus-sasl,esound,expat,fontconfig,freetype,fribidi,gcc,giflib,glib2,glibc-solibs,gpm,gtk+2,lcms,libX11,libXScrnSaver,libXau,libXcomposite,libXcursor,libXdamage,libXdmcp,libXext,libXfixes,libXi,libXinerama,libXrandr,libXrender,libXv,libXxf86dga,libXxf86vm,libcaca,libcap,libdrm,libjpeg,libmad,libmng,libogg,libpng,libtheora,libxcb,lzo,mesa,ncurses,openldap-client,openssl | openssl-solibs,pango,pixman,samba,sdl,slang,svgalib,zlib
PACKAGE CONFLICTS: 
PACKAGE SUGGESTS: 
PACKAGE DESCRIPTION:
MPlayer: MPlayer (media player)
MPlayer:
MPlayer: MPlayer is a movie player.  It plays most MPEG/VOB, AVI, Ogg/OGM,
MPlayer: VIVO, ASF/WMA/WMV, QT/MOV/MP4, RealMedia, Matroska, NUT, NuppelVideo,
MPlayer: FLI, YUV4MPEG, FILM, RoQ, PVA files, supported by many native, XAnim,
MPlayer: and Win32 DLL codecs.  You can watch VideoCD, SVCD, DVD, 3ivx,
MPlayer: DivX 3/4/5, WMV and even H.264 movies.
MPlayer:
MPlayer: Homepage for MPlayer is http://www.mplayerhq.hu/
MPlayer:

PACKAGE NAME:  PyQt-4.7.3-i486-1.txz
PACKAGE MIRROR: http://slackware.cs.utah.edu/pub/slackware/slackware-13.1/
PACKAGE LOCATION:  ./slackware/l
PACKAGE SIZE (compressed):  7548 K
PACKAGE SIZE (uncompressed):  34550 K
PACKAGE REQUIRED:  alsa-lib,cxxlibs | gcc-g++,dbus,expat,fontconfig,freetype,gcc,glib2,glibc-solibs,libICE,libSM,libX11,libXau,libXdamage,libXdmcp,libXext,libXfixes,libXrender,libXxf86vm,libdrm,libpng,libxcb,mesa,python,qt,sqlite,util-linux-ng,zlib
PACKAGE CONFLICTS: 
PACKAGE SUGGESTS: 
PACKAGE DESCRIPTION:
PyQt: PyQt (Python bindings for Qt)
PyQt:
PyQt: PyQt is a set of Python bindings for Trolltech's Qt application
PyQt: framework and runs on all platforms supported by Qt.
PyQt:
PyQt:
PyQt: Homepage: http://www.riverbankcomputing.co.uk/software/PyQt/
PyQt:

PACKAGE NAME:  QScintilla-2.4.3-i486-1.txz
PACKAGE MIRROR: http://slackware.cs.utah.edu/pub/slackware/slackware-13.1/
PACKAGE LOCATION:  ./slackware/l
PACKAGE SIZE (compressed):  1108 K
PACKAGE SIZE (uncompressed):  8500 K
PACKAGE REQUIRED:  cxxlibs | gcc-g++,expat,fontconfig,freetype,gcc,glib2,glibc-solibs,libICE,libSM,libX11,libXau,libXdmcp,libXext,libXrender,libpng,libxcb,mesa,perl,python,qt,util-linux-ng,zlib
PACKAGE CONFLICTS: 
PACKAGE SUGGESTS: 
PACKAGE DESCRIPTION:
QScintilla: QScintilla (Qt port of the Scintilla C++ editor control)
QScintilla:
QScintilla: QScintilla includes features especially useful when editing and
QScintilla: debugging source code.  These include support for syntax styling,
QScintilla: error indicators, code completion, and call tips.  The selection
QScintilla: margin can contain markers like those used in debuggers to
QScintilla: indicate breakpoints and the current line.  Styling choices are
QScintilla: more open than with many editors, allowing the use of
QScintilla: proportional fonts, bold and italics, multiple foreground and
QScintilla: background colours, and multiple fonts.
QScintilla:

PACKAGE NAME:  a2ps-4.14-i486-3.txz
PACKAGE MIRROR: http://slackware.cs.utah.edu/pub/slackware/slackware-13.1/
PACKAGE LOCATION:  ./slackware/ap
PACKAGE SIZE (compressed):  720 K
PACKAGE SIZE (uncompressed):  4350 K
PACKAGE REQUIRED:  glibc-solibs,perl,python
PACKAGE CONFLICTS: 
PACKAGE SUGGESTS: 
PACKAGE DESCRIPTION:
a2ps: a2ps (any to PostScript filter)
a2ps:
a2ps: GNU a2ps is an Any to PostScript filter.  Of course it processes
a2ps: plain text files, but also pretty prints quite a few popular
a2ps: programming languages.  Also contained in this package is psutils, a
a2ps: collection of programs for manipulating PostScript files.
a2ps:
a2ps: a2ps is used by Apsfilter, so be sure to install this package if you
a2ps: plan to do any printing.
a2ps:

PACKAGE NAME:  aaa_base-13.1-i486-2.txz
PACKAGE MIRROR: http://slackware.cs.utah.edu/pub/slackware/slackware-13.1/
PACKAGE LOCATION:  ./slackware/a
PACKAGE SIZE (compressed):  12 K
PACKAGE SIZE (uncompressed):  90 K
PACKAGE REQUIRED: 
PACKAGE CONFLICTS: 
PACKAGE SUGGESTS: 
PACKAGE DESCRIPTION:
aaa_base: aaa_base (Basic Linux filesystem package)
aaa_base:
aaa_base: Sets up the empty directory tree for Slackware and adds an email to
aaa_base: root's mailbox welcoming them to Linux. :)  This package should be
aaa_base: installed first, and never uninstalled.
aaa_base:

PACKAGE NAME:  aaa_elflibs-13.1-i486-1.txz
PACKAGE MIRROR: http://slackware.cs.utah.edu/pub/slackware/slackware-13.1/
PACKAGE LOCATION:  ./slackware/a
PACKAGE SIZE (compressed):  4088 K
PACKAGE SIZE (uncompressed):  13000 K
PACKAGE REQUIRED:  attr,cups,cxxlibs | gcc-g++,cyrus-sasl,gcc,glib2,glibc-solibs,gmp,libidn,libjpeg,libpng,libtiff,libusb,ncurses,openldap-client,openssl | openssl-solibs,pcre,udev,zlib
PACKAGE CONFLICTS: 
PACKAGE SUGGESTS: 
PACKAGE DESCRIPTION:
aaa_elflibs: aaa_elflibs (shared libraries needed by many programs)
aaa_elflibs:
aaa_elflibs: This is a collection of shared libraries needed to run Linux programs.
aaa_elflibs: ELF (Executable and Linking Format) is the standard Linux binary
aaa_elflibs: format.  These libraries are gathered from other Slackware packages
aaa_elflibs: and are intended to give a fairly complete initial set of libraries.
aaa_elflibs: This package should be not upgraded or reinstalled (it could copy
aaa_elflibs: over newer library versions).
aaa_elflibs:

PACKAGE NAME:  aaa_terminfo-5.7-noarch-1.txz
PACKAGE MIRROR: http://slackware.cs.utah.edu/pub/slackware/slackware-13.1/
PACKAGE LOCATION:  ./slackware/a
PACKAGE SIZE (compressed):  44 K
PACKAGE SIZE (uncompressed):  690 K
PACKAGE REQUIRED: 
PACKAGE CONFLICTS: 
PACKAGE SUGGESTS: 
PACKAGE DESCRIPTION:
aaa_terminfo: aaa_terminfo (a basic collection of terminfo entries)
aaa_terminfo:
aaa_terminfo: This is a starter set of files from the terminfo database, which
aaa_terminfo: should be enough in most cases.  The complete set (from which this
aaa_terminfo: is derived) can be found in the ncurses package.
aaa_terminfo:
aaa_terminfo: The terminfo database describes the characteristics of terminals, so
aaa_terminfo: don't try to log in without this package.  :-)
aaa_terminfo:

PACKAGE NAME:  aalib-1.4rc5-i486-2.txz
PACKAGE MIRROR: http://slackware.cs.utah.edu/pub/slackware/slackware-13.1/
PACKAGE LOCATION:  ./slackware/l
PACKAGE SIZE (compressed):  164 K
PACKAGE SIZE (uncompressed):  510 K
PACKAGE REQUIRED:  glibc-solibs,gpm,libX11,libXau,libXdmcp,libxcb,slang
PACKAGE CONFLICTS: 
PACKAGE SUGGESTS: 
PACKAGE DESCRIPTION:
aalib: aalib (ASCII Art library)               _1l1vlvlvlvlvlvlvlvlvvl=.
aalib:                                      __111llvl+' __...._   +1lv11=.
aalib: AA-lib is an ASCII art graphics     _11vllvlv+  =vlvlvl1=  /1vlvv1i=_
aalib: library.  Internally, the AA-lib   _vvllvlvlv=  -+vlvlvlvlvlvlvlvdvl=_
aalib: API is similar to other graphics  _:lvlvlvlvlv=.     --^-^1lvlvlrlvv1s
aalib: libraries, but it renders the     =llvlvvlvlvv11lvl=....   -lvlevlvlvv
aalib: the output into ASCII art (like   =lvlvlvlvll-^+1vv11111v_  vlkllvllvl
aalib: the example to the right :^)      =lvlvlvlvl1   +1vv1v1lv  _llvlvlvlvl
aalib: The developers of AA-lib are       +1lv |vlvl'    -^-^-   _1olvlvlvlv'
aalib: Jan Hubicka, Thomas A. K. Kjaer,   -1vl |lvlvlvlvlvlvlvlvv1vlvlvlvlv+.
aalib: Tim Newsome, and Kamil Toman.        +1 ^^^^^^^^^^^^^^^^^^^^^^^^vlv-
aalib:                                       -+uvlvlvlvlvlvlvlvlvlvlvlvl+_
aalib:                                          -vlvlvlvlvlvlvlvllvlvl-'

PACKAGE NAME:  acct-6.4pre1-i486-1.txz
PACKAGE MIRROR: http://slackware.cs.utah.edu/pub/slackware/slackware-13.1/
PACKAGE LOCATION:  ./slackware/ap
PACKAGE SIZE (compressed):  92 K
PACKAGE SIZE (uncompressed):  270 K
PACKAGE REQUIRED:  glibc-solibs
PACKAGE CONFLICTS: 
PACKAGE SUGGESTS: 
PACKAGE DESCRIPTION:
acct: acct (process accounting utilities)
acct:
acct: This is a set of utilities which reports and summarizes data about
acct: user connect times and process execution statistics.  To activate
acct: process accounting, create the log file (touch /var/log/pacct), and
acct: then use the accton command to start it (accton /var/log/pacct).
acct: Be aware that the log file can grow to be quite large.
acct:
acct: The GNU process accounting utilities were written by Noel Cragg and
acct: the software is currently maintained by Ciaran O'Riordan,
acct: Manuel A. Fernandez Montecelo, and Tim Schmielau.

and the story continue...
Credits to STEFANO STABELLINI

Last edited by Darth Vader; 02-19-2011 at 01:48 PM.
 
Old 02-19-2011, 01:54 PM   #1106
55020
Member
 
Registered: Sep 2009
Location: Yorks. W.R. 167397
Distribution: Slackware
Posts: 434
Blog Entries: 4

Rep: Reputation: 438Reputation: 438Reputation: 438Reputation: 438Reputation: 438
Quote:
Originally Posted by AlvaroG View Post
you are already doing this work each time you write "this package depends on program a, b, c, and d, and optionally on e and f" in the SlackBuild description. So I don't see how bad it could be to give that information a standard format that sbopkg can understand and use to build a queue.
Actually, in the special case of SlackBuild descriptions, I tend to agree with you Those words "depends on ... and optionally on" make source based SlackBuilds more flexible than any dependency checking system, and I could easily write them in both English and XML.

But when I write those words, I usually feel bad, because the real story is always much more complicated. For example, when I write that darktable depends on lensfun, the whole truth is that it builds ok without lensfun, but you won't get lens correction (duh) which is a documented feature. And when I write that qgis depends on qwt, the whole truth is that qgis is happy without it, but a whole set of recently added features will be absent. I could probably write a whole README about the exact version numbers and the exact effects of each dependency. But it really would frighten people unnecessarily and it would be wrong as soon as there was a new version of an upstream dependency.

So I just write "this package depends on program a, b, c, and d, and optionally on e and f" and run away
 
1 members found this post helpful.
Old 02-19-2011, 02:04 PM   #1107
Darth Vader
Member
 
Registered: May 2008
Location: Romania
Distribution: DARKSTAR Linux 2008.1
Posts: 659

Rep: Reputation: 138Reputation: 138
Quote:
Originally Posted by 55020 View Post
I could probably write a whole README about the exact version numbers and the exact effects of each dependency.
Believe or not, that's exactly what the (OPEN)SUSE, UBUNTU or REDHAT (professional) packagers do...
 
Old 02-19-2011, 03:55 PM   #1108
gnashley
Amigo developer
 
Registered: Dec 2003
Location: Germany
Distribution: Slackware
Posts: 4,775

Rep: Reputation: 481Reputation: 481Reputation: 481Reputation: 481Reputation: 481
Creating a dependency-resolving system means being able to massage the contents and format of the packages themselves. Of course there is no sense in talking about it here as it will never happen. But, the use and acceptance of sbopkg queue files shows that not everyone here is against a little guidance when it comes to resolving dependencies. As Darth Vader points out, the 'big' distros provide both a system and the data necessary to resolve dependencies -however badly- and they document in prose the ins and outs of the optional requirements.

I built a system of generating requires info into src2pkg which provides a lot of info -but that's all. src2pkg doesn't aim to resolve depends, but it can provide a pretty rich set of data to make it possible or just to be able to review or inform yourself when building something -a lot of packages have really surprising requirements that you would never imagine without doing a full investigation I'm thinking just now of later versions or rpm depending on some libs from seamonkey.

Anyway, besides providing the info on what other packages a package depends on (including the individual libraries), src2pg can also create a meta-data file which shows even more info about the package inclduing the configure options, a list of patches applied, the version of gcc, binutils, and glibc that were used to compile it, the hostname of the machine it was compiled on, and so on.

Here's a couple of example files generated by src2pkg:
slack-required
Code:
# xarchive-0.2.8 
# Requires:                              |Supplied by:                           
# File: libatk-1.0.so.0.1114.0           |: atk                                  
# File: libcairo.so.2.11.7               |: cairo                                
# File: libgdk-x11-2.0.so.0.800.20       |: gtk+2                                
# File: libgdk_pixbuf-2.0.so.0.800.20    |: gtk+2                                
# File: libglib-2.0.so.0.1400.6          |: glib2                                
# File: libgmodule-2.0.so.0.1400.6       |: glib2                                
# File: libgobject-2.0.so.0.1400.6       |: glib2                                
# File: libgtk-x11-2.0.so.0.800.20       |: gtk+2                                
# File: libpango-1.0.so.0.1201.2         |: pango                                
# File: libpangocairo-1.0.so.0.1201.2    |: pango                                
atk
cairo
glib2
gtk+2
pango
meta-data:
Code:
# Package: xarchive-0.2.8-i486-1.tgz
# Created by: 'src2pkg'  on hostname: slackpre11
# Date: Sat Feb 19 21:43:10 CET 2011
# Processor: pentium3 i686

# Kernel: 2.4.37.rc1 #4 Tue Nov 25 10:51:21 CET 2008
# TOOLCHAIN:
# LIBC: GNU C Library stable release version 2.3.6
#       Compiled by GNU CC version 3.4.6.
#       Compiled on a Linux 2.4.33.3 system on 2006-09-14.
# COMPILER: GCC-3.4.6 i486-slackware-linux
# BINUTILS: version 2.15.92.0.2 20040927

# Source name: xarchive-0.2.8-6.tar.gz
# Patchlist goes here when used
# Nominal architecture: i486
# Build configuration:
	LDFLAGS="-Wl,-L/lib,-L/usr/lib,--relax,--sort-common,--no-keep-memory" \
	CFLAGS="-O2 -m32 -pipe -fomit-frame-pointer -march=i486 -mtune=i686" \
	CXXFLAGS="-O2 -m32 -pipe -fomit-frame-pointer -march=i486 -mtune=i686" \
	./configure --prefix=/usr --libdir=/usr/lib
I find it quite informative to look at the requireds for a package *as information*. It seems to me that the very religious around here are on a slippery slope if they are actually using sbopkg queue files... This could end up like what happened with the unstable kernel 2.6, udev, hal, pol-kit (and next maybe PAM??), where suddenly what was evil and forbidden for slackers becomes the Right Stuff...
 
Old 02-19-2011, 04:26 PM   #1109
bgeddy
Senior Member
 
Registered: Sep 2006
Location: Liverpool - England
Distribution: slackware64 13.37 and -current, Dragonfly BSD
Posts: 1,810

Rep: Reputation: 227Reputation: 227Reputation: 227
Quote:
It seems to me that the very religious around here are on a slippery slope if they are actually using sbopkg queue files... This could end up like what happened with the unstable kernel 2.6, udev, hal, pol-kit (and next maybe PAM??), where suddenly what was evil and forbidden for slackers becomes the Right Stuff...
Whilst I wouldn't class myself as being "very religious" I do appreciate Slackware's approach to package and, more appropriately, dependency management. I also really enjoy the benefits of the pre-built sbopkg queue files - they have saved me a lot of time in checking and tracking down stuff when building a package. So I'd appreciate it if you could explain what you meant here as I think I'm missing your point somewhat. Well, it is Saturday night here , so that's my excuse. BTW, I don't agree with any form of automatic dependency management in Slackware - obviously I don't class sbopkg queues as one of these.

Last edited by bgeddy; 02-19-2011 at 04:27 PM.
 
Old 02-20-2011, 02:05 AM   #1110
gnashley
Amigo developer
 
Registered: Dec 2003
Location: Germany
Distribution: Slackware
Posts: 4,775

Rep: Reputation: 481Reputation: 481Reputation: 481Reputation: 481Reputation: 481
"I don't class sbopkg queues as [automatic dependency management]", Uh what would you call it then?

What I meant was that some day, dependency management might be included in Slackware and be considered a magical wonderful thing -even after being cursed for so long, just as with the other things I mentioned. I was being sarcastic, though.

I totally agree that having a package installer that won't do what I want it to is not a good thing. But I also sympathize with users who don't know anything about package management and don't want to. There are plenty of other distros for those types of people. Still, 'install everything or nothing is guaranteed to work' seems rather lame -assuming that that really were the case. On a regular basis we see postings where after upgrading something, something else ceases to work. Usually this is due to that second something not being re-compiled against the first something. As a developer, I'd want some way to alert myself to these things before releasing them. That's where even a crude system which dependency *information* would come in very handy.

The system I have worked out does exactly that and with a tiny script can tell me both the requirements of any package and also the packages that depend on it. Very handy indeed. I even have a script which will work out a compile order list for everything installed -of course it needs some adjusting for a few packages -to avoid creating unwanted dependencies for some packages -and it's not meant to be a create-from-scratch build order.

In short, having good dependency info is a great time-saver. And so is having a package manager that doesn't cripple you by doing its' own thing.
 
6 members found this post helpful.
  


Reply

Tags
cd, live


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
Slackware future? coyctecm Slackware 12 02-01-2006 11:03 PM
Future of Slackware kratunko Slackware 30 08-12-2005 01:31 PM
Slackware features? rusty_slacker Slackware 49 12-02-2004 05:45 AM
what are the features of the new slackware 9? ethanchic Slackware 2 09-27-2002 07:15 PM


All times are GMT -5. The time now is 08:29 PM.

Main Menu
Advertisement
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