LinuxQuestions.org
Visit Jeremy's Blog.
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 12-02-2017, 06:30 PM   #31
Didier Spaier
LQ Addict
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slint64-14.2 on Lenovo Thinkpad W520
Posts: 7,867

Rep: Reputation: 2780Reputation: 2780Reputation: 2780Reputation: 2780Reputation: 2780Reputation: 2780Reputation: 2780Reputation: 2780Reputation: 2780Reputation: 2780Reputation: 2780

Quote:
Originally Posted by ivandi View Post
It is a common mistake to think that dependency resolution will automagically solve the problem with the full install. Slackware does not split packages. For example if you use slapt-get to install wpa_supplicant on a minimal system, it will pull everything and the kitchen sink. Wpa gui depends on QT, QT depend on gcc gcc-c++ Xlibs and mesa, mesa pulls llvm and so on, you get the picture.
Let me quote this:
Quote:
PACKAGE NAME: wpa_supplicant-2.5-x86_64-1.txz
PACKAGE LOCATION: ./slackware64/n PACKAGE SIZE (compressed): 1008 K PACKAGE SIZE (uncompressed): 2940 K
PACKAGE REQUIRED: o work?bzip2,dbus,expat,fontconfig,freetype,gcc,gcc-g++,glib2,harfbuzz,libICE,libSM,libX11,libXau,libXdmcp,libXext,libXrender,libffi,libnl3,libpng,libxc b,ncurses,openssl-solibs|openssl,qt,readline,util-linux,zlib
Of course that's a lot. So what? If that's actually what is needed (I didn't check as I never make a minimal installation) what's wrong in installing what's needed for the newly installed wpa_supplicant to work?

Anyway I didn't say that there is a problem with a full install. In Slint only a full install is proposed (just KDE is becoming optional). By the way in Salix the wpa GUI is not shipped in wpa_supplicant to avoid installing Qt just for that.

Now if you mean that the Slackware packaging way or method leads to added (or what one could call "artificial") dependencies, I agree. For instance it makes akonadi a dependency of a lot more packages than those that ship apps actually needing it.

But this makes Slackware very versatile out of the box, and splitting the packages as do other distributions would mean an amount of maintenance work that I assume Pat and contributors just can't handle.

Last edited by Didier Spaier; 12-02-2017 at 06:34 PM.
 
Old 12-02-2017, 06:48 PM   #32
LuckyCyborg
Member
 
Registered: Mar 2010
Posts: 274

Rep: Reputation: 72
The amount of maintenance work that Patrick Volkerding assume is connected also with his own preferences, to use those build scripts where he write every step of the process.

Slackware is not the only distribution using bash scripts to build packages. Look how the Arch do it - I get first package from the list.
Code:
# $Id$
# Maintainer: Sven-Hendrik Haase <sh@lutzhaase.com>
# Contributor: t3ddy  <t3ddy1988 "at" gmail {dot} com>
# Contributor: Adrián Chaves Fernández (Gallaecio) <adriyetichaves@gmail.com>
pkgname=0ad
pkgver=a22
_pkgver=0.0.22-alpha
pkgrel=3
pkgdesc="Cross-platform, 3D and historically-based real-time strategy game"
arch=('x86_64')
url="http://play0ad.com/"
license=('GPL2' 'CCPL')
depends=('binutils' 'boost-libs' 'curl' 'enet' 'libogg' 'libpng' 'libvorbis'
         'libxml2' 'openal' 'sdl2' 'wxgtk' 'zlib' 'libgl' '0ad-data' 'glu'
         'gloox' 'miniupnpc' 'icu' 'nspr')
makedepends=('boost' 'cmake' 'mesa' 'zip' 'python2' 'libsm')
source=("http://releases.wildfiregames.com/$pkgname-$_pkgver-unix-build.tar.xz")
sha512sums=('3f917e77c6cc1d3fb585c98950db6eab3f5895ba3db41a8737f8172c769b5582689b436cab31eeafecce0e9639ee456afc7b78ebb03435b06512eb9fe7393771')

prepare() {
  cd "$srcdir/$pkgname-$_pkgver/"
  sed -i "s/env python/env python2/g" libraries/source/cxxtest-4.4/bin/cxxtestgen
}

build() {
  cd "$srcdir/$pkgname-$_pkgver/build/workspaces"

  unset CPPFLAGS # for le spidermonkey

  ./update-workspaces.sh \
      --bindir=/usr/bin \
      --libdir=/usr/lib/0ad \
      --datadir=/usr/share/${pkgname}/data

  cd "$srcdir/$pkgname-$_pkgver/build/workspaces/gcc"

  make
}

package() {
  install -d "${pkgdir}"/usr/{bin,lib/0ad,share/"${pkgname}"/data}
  cd "$srcdir/$pkgname-$_pkgver"

  install -Dm755 binaries/system/pyrogenesis "${pkgdir}/usr/bin"
  install -Dm755 binaries/system/*.so "${pkgdir}/usr/lib/0ad"

  cp -r binaries/data/l10n/ ${pkgdir}/usr/share/${pkgname}/data/

  install -Dm755 build/resources/${pkgname}.sh "${pkgdir}/usr/bin/${pkgname}"
  install -Dm644 build/resources/${pkgname}.desktop \
    "${pkgdir}/usr/share/applications/${pkgname}.desktop"
  install -Dm644 build/resources/${pkgname}.png \
    "${pkgdir}/usr/share/pixmaps/${pkgname}.png"
}

# Fails
#check() {
#  cd "$srcdir/$pkgname-$_pkgver"
#  LD_LIBRARY_PATH=binaries/system binaries/system/test
#}
What I want to say is: the Slackware maintainer works much much more for the same task, compared with other maintainers, because he prefer the "raw" scripts, where he control punctually everything.

No one can stop him to simplify his work, using a PKGBUILD like Arch, if he wants. It is also about preferences.

Last edited by LuckyCyborg; 12-02-2017 at 06:50 PM.
 
Old 12-02-2017, 06:59 PM   #33
Didier Spaier
LQ Addict
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slint64-14.2 on Lenovo Thinkpad W520
Posts: 7,867

Rep: Reputation: 2780Reputation: 2780Reputation: 2780Reputation: 2780Reputation: 2780Reputation: 2780Reputation: 2780Reputation: 2780Reputation: 2780Reputation: 2780Reputation: 2780
@ LuckyCyborg: I write SlackBuilds but also SLKBUILDs, mostly used by Salix to which I borrow the slkbuild application that process the SLKBUILDs, and very much doubt that makes a so big difference. Pat even writes the VERSION in such a way that it sets itself as the one in the source archive's name. The time spent in testing is certainly of an order of magnitude bigger than the one spent in editing the scripts, anyway.
 
Old 12-02-2017, 07:01 PM   #34
Launfal
Member
 
Registered: Jun 2014
Location: Ohio, USA
Posts: 65

Rep: Reputation: 49
I get what Darth is saying, and I sympathize, being a minimalist at heart, but after some reading and thinking, I've pretty much come around to the "install it all and use what I need" camp.

If I disabuse myself of the notion that package sets are intended in some way to make it easier to install subsets of Slack and instead treat them as a legacy from when Slack had to be divided up to fit on diskettes/CD's, then I get closer to understanding that I should be treating them like they don't even exist. Then, if I take that thought one step further, I'm almost forced to the conclusion that they shouldn't exist on the DVD at all, and the installer should just do an image dump of the whole shebang and call it a day.

IMO, their existence does send a kind of mixed message with regards to what's recommended/supported and what people (myself included) are trying to do with them. Trying to force package sets to be something they're not is only going to frustrate people on both sides of the "install it all" fence, and maybe consideration should be given to simply removing them.

Slack supports tagfiles, and maybe that should be the only way to go to install subsets of Slack-64. Maybe package sets are still needed for Slack-32, but I don't know since I don't use it.
 
1 members found this post helpful.
Old 12-02-2017, 07:18 PM   #35
LuckyCyborg
Member
 
Registered: Mar 2010
Posts: 274

Rep: Reputation: 72
You figured out that if the maintainer would accept the proposal from this thread, there is no more need for splitting the packages in folders/sets and maybe no need even for the tagfiles?

Imagine all packages put in a single directory "slackware", the installer shows a list of groups to be installed if not all, then with grepping in the *.txt files, merging all results and doing unique and sort, you obtain a nice list of packages to install.

Leaving the heated thoughts away, I think this will be a great improvement while simplifying the things. But that's me, of course is my personal opinion.
 
Old 12-02-2017, 07:25 PM   #36
Darth Vader
Senior Member
 
Registered: May 2008
Location: Romania
Distribution: DARKSTAR Linux 2008.1
Posts: 1,647

Original Poster
Rep: Reputation: 590Reputation: 590Reputation: 590Reputation: 590Reputation: 590Reputation: 590
Quote:
Originally Posted by LuckyCyborg View Post
What I want to say is: the Slackware maintainer works much much more for the same task, compared with other maintainers, because he prefer the "raw" scripts, where he control punctually everything.
He does not needs to adopt the Arch's PKGBUILD if he wants to change his workflow in some way.

He has at disposition Weapons of Mass Destruction, in the form of meta-builds from X11 and KDE, from years ago.

To be host, I expected, in those years, our BDFL to transform in meta-builds almost everything, because they are powerful like the nuclear devices.

Last edited by Darth Vader; 12-02-2017 at 07:38 PM.
 
Old 12-02-2017, 07:30 PM   #37
Darth Vader
Senior Member
 
Registered: May 2008
Location: Romania
Distribution: DARKSTAR Linux 2008.1
Posts: 1,647

Original Poster
Rep: Reputation: 590Reputation: 590Reputation: 590Reputation: 590Reputation: 590Reputation: 590
Quote:
Originally Posted by LuckyCyborg View Post
Imagine all packages put in a single directory "slackware", the installer shows a list of groups to be installed if not all, then with grepping in the *.txt files, merging all results and doing unique and sort, you obtain a nice list of packages to install.
Nice idea. BUT, even maybe that concept could be used the way you describe, YET I do not proposed changes like that. Lets be clear here.

My idea is all about a way of storing information about a particular package purpose, not about resolving dependencies, automatically or not, or changing the installer and putting all packages in a single directory.

Last edited by Darth Vader; 12-02-2017 at 07:46 PM.
 
Old 12-02-2017, 08:13 PM   #38
Launfal
Member
 
Registered: Jun 2014
Location: Ohio, USA
Posts: 65

Rep: Reputation: 49
Quote:
Originally Posted by LuckyCyborg View Post
You figured out that if the maintainer would accept the proposal from this thread, there is no more need for splitting the packages in folders/sets and maybe no need even for the tagfiles?
Actually, I realized that whether the maintainer accepts the proposal or not, (1) the existence of package sets run counter to the recommended/supported installation, and that they should probably be removed to eliminate any confusion on that point, and (2) paring down the install should be left as an exercise for the system admin/user.

Tagfiles are still useful, and while I've never really played with them, knowing the build dependencies for packages I don't want should make them reasonably easy for me to write if I was so inclined. That's just more work than I can justify for MY use case. YMMV.
 
Old 12-02-2017, 08:27 PM   #39
heyjann
Member
 
Registered: Dec 2015
Posts: 72

Rep: Reputation: Disabled
Darth Vader, I am curious, how would you describe the purpose of let's say libpng and harfbuzz that's not already covered by PACKAGES.txt?

I am sure that if I decide I do not like them, and uninstall them, I will need to do a lot of recompiling of other software, at the very least.
Of the two I suppose that libpng will be an optional dependency a few times more often, for example imagemagick might accept being recompiled to 'only' support all the other image types. But I'm not even sure of that.
 
1 members found this post helpful.
Old 12-02-2017, 09:04 PM   #40
LuckyCyborg
Member
 
Registered: Mar 2010
Posts: 274

Rep: Reputation: 72
Quote:
Originally Posted by Launfal View Post
Actually, I realized that whether the maintainer accepts the proposal or not, (1) the existence of package sets run counter to the recommended/supported installation, and that they should probably be removed to eliminate any confusion on that point, and (2) paring down the install should be left as an exercise for the system admin/user.
But you really believe that an unconditional full install is always better? What if this full install create huge problems in reaching the supposed usage of the installation?

Lets take the OP case. I do not try to defend him, but there is raised a real issue, which I would like to note.

If you had the patience to read some of his posts, he always talks about two things, when does not try to help someone.

One thing is that PAM addition would help the the users which use the Slackware in an environment somehow connected with corporate and office. Lets jump over this part, having no importance in our discussion.

Second thing about which he talks, is that he should continue to use KDE4, even after the adoption of KDE5, and have no importance his reasons to do that.

Could be a strong dislike for KDE5 or could be some proprietary software which he use for his activity, and that software must requiring KDE4. Who know? We could ask him to precisely known why.

Just like him, I am aware that the KDE4 will be replaced by KDE5, in one day. Sooner, or later will happen.

Trying to be on his skin, the question is how you completely remove the KDE5 and its dependencies, and to install back the KDE4, when this day come?

Which packages should be removed, to make that possible?

The problem is that no one know, even the maintainer claiming to not keeping a list of packages sorted by their dependencies, while the general recommendation, with winks or not, is to do it yourself. Sure, you do it yourself, but what you have to remove?

In fact, I will ask you if today we know how to remove the KDE4 with its every dependency?

Because I seen only a partial uninstall solution, given by Eric Hameleers for installation of KDE5.

I think there we hit the real issue: the Slackware is today dependent by KDE, and no one know how to fully remove it. Even the maintainer.

Or simply we cannot remove it without breaking the operating system. That's the real issue to think about, not the package groups or whatever.
 
Old 12-02-2017, 09:10 PM   #41
Darth Vader
Senior Member
 
Registered: May 2008
Location: Romania
Distribution: DARKSTAR Linux 2008.1
Posts: 1,647

Original Poster
Rep: Reputation: 590Reputation: 590Reputation: 590Reputation: 590Reputation: 590Reputation: 590
Quote:
Originally Posted by heyjann View Post
Darth Vader, I am curious, how would you describe the purpose of let's say libpng and harfbuzz that's not already covered by PACKAGES.txt?

I am sure that if I decide I do not like them, and uninstall them, I will need to do a lot of recompiling of other software, at the very least.
Of the two I suppose that libpng will be an optional dependency a few times more often, for example imagemagick might accept being recompiled to 'only' support all the other image types. But I'm not even sure of that.
Libraries

You know well about what I talk, BTW...

And I do not talk about resolving dependencies, automatically or not.

Instead, I talk about groups or "categories", just like you have a site, where you can have a image gallery, where you can dump everything having a page with 1200 images, or you can organize the images on categories, on sub-categories and so on.

Oh, and BTW...

You can safely remove both the libpng and harfbuzz, if your operating system purpose is just a headless network file server. Last I checked the BASH and NFS mount utilities does not depends on libpng.

Last edited by Darth Vader; 12-02-2017 at 09:38 PM.
 
Old 12-02-2017, 09:19 PM   #42
Darth Vader
Senior Member
 
Registered: May 2008
Location: Romania
Distribution: DARKSTAR Linux 2008.1
Posts: 1,647

Original Poster
Rep: Reputation: 590Reputation: 590Reputation: 590Reputation: 590Reputation: 590Reputation: 590
@LuckyCyborg

Yes, I use for my job some proprietary software, software which require the KDE4 and Qt4. I like or not, I should continue to use KDE4.

Also I dislike that Plasma5, specially its wonderful stability until now. I use the computers for work, not as a plaything, where is no issue a "little" crash.

Worry not, I will find a solution to keep working the KDE4, at least for my own private use.

Last edited by Darth Vader; 12-02-2017 at 09:39 PM.
 
Old 12-02-2017, 09:47 PM   #43
LuckyCyborg
Member
 
Registered: Mar 2010
Posts: 274

Rep: Reputation: 72
I am pretty sure that you will find a solution for your problem, as I see that you act proactively and I know that you are not a beginner in Linux.

But our problem will remain. In fact, could be removed the KDE? How? Which are those packages to be removed?
 
Old 12-02-2017, 10:12 PM   #44
Darth Vader
Senior Member
 
Registered: May 2008
Location: Romania
Distribution: DARKSTAR Linux 2008.1
Posts: 1,647

Original Poster
Rep: Reputation: 590Reputation: 590Reputation: 590Reputation: 590Reputation: 590Reputation: 590
IF you ask me, to remove the KDE is simple, to remove all its dependencies is not so easy, because there are many libraries which are put in the L series, and they have a main utility for KDE.

Then is the Qt. For me is simple: I should stay with the Qt4 in the foreseeable future.

BUT from a general POV, you will treat Qt and its dependencies as belonging to KDE, or stand-alone support libraries?

Sadly, the problem is much more complicated than those libpng and harfbuzz things.

Overall you can say that KDE blended so much in the operating system, that removing it with all its dependencies, you have no more Slackware.

Last edited by Darth Vader; 12-02-2017 at 10:15 PM.
 
Old 12-02-2017, 10:14 PM   #45
Launfal
Member
 
Registered: Jun 2014
Location: Ohio, USA
Posts: 65

Rep: Reputation: 49
Quote:
Originally Posted by LuckyCyborg View Post
But you really believe that an unconditional full install is always better? What if this full install create huge problems in reaching the supposed usage of the installation?
Absolutely not. I'm just making the point that a full install is the only _supported_ install. If we want to do anything else, we shouldn't be looking for the maintainers to make it easier. A little more on that below.

Quote:
Lets take the OP case. I do not try to defend him, but there is raised a real issue, which I would like to note.
There absolutely is, and I've already said I understand the sentiment. He's just ice-skating uphill.

Quote:
I think there we hit the real issue: the Slackware is today dependent by KDE, and no one know how to fully remove it. Even the maintainer.
IMO, the real issue is that Slackware of today is designed to be monolithic. The package sets make it seem modular, but it's really not. It's designed to be installed and maintained as a whole, and anyone suggesting that the maintainer take steps to go against that vision is going to meet resistance.

Quote:
Or simply we cannot remove it without breaking the operating system. That's the real issue to think about, not the package groups or whatever.
That is more a consequence of its design. It's not meant to be broken apart and uninstalled in pieces, and the fact that it's even possible at all is a tribute to that design. I don't use either DE, so I absolutely understand a sentiment against having to install them "just because", but I'm not willing to jump through hoops to completely sanitize my system of them.
 
2 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
"No volume groups found" when using LVM to decrease partition size dj_thrive Linux - Enterprise 6 10-05-2017 06:21 PM
where is "Users and Groups" in Debian "Wheezy" ? StefanP Linux - Newbie 10 04-28-2014 04:37 PM
How do you move groups of sectors in a hard drive using the "dd" command? cross731 Linux - Newbie 4 09-20-2011 06:14 PM
A proposal regarding the _registration_ of package dependencies by Pkgtools Darth Vader Slackware 13 07-13-2011 06:01 AM
Error: "cannot set groups" by using "su -", pls help nelsonyuen Linux - General 14 07-31-2010 01:24 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 08:24 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
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration