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-03-2017, 05:53 AM   #46
GazL
Senior Member
 
Registered: May 2008
Posts: 4,519
Blog Entries: 9

Rep: Reputation: 2003Reputation: 2003Reputation: 2003Reputation: 2003Reputation: 2003Reputation: 2003Reputation: 2003Reputation: 2003Reputation: 2003Reputation: 2003Reputation: 2003

Quote:
Originally Posted by Launfal View Post
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.

But they are intended to make it easier to install subsets: it's just not a complete solution.

E,F,KDE,XFCE, and a few other minor ones can all be left off if someone doesn't want those subsets. What they're not is a completely self contained selection point and things like the L set are a little more complicated.

As an example, this is how I currently keep updated with current:
Code:
rsync -avz --delete --delete-excluded \
      --partial --timeout=60 \
      --exclude='/slackware64-current/source/' \
      --exclude='/slackware64-current/slackware64/k/' \
      --exclude='/slackware64-current/slackware64/kde/' \
      --exclude='/slackware64-current/slackware64/kdei/' \
      "$MIRROR" "$DESTDIR"
Yes, there's some KDE specific stuff in the L set that I don't really require, but I don't need to remove it all to get benefit from only syncing a subset. I save a lot of bandwidth and disk space -- though disk space is not all that relevant these days -- doing this.

No longer having sets at all in the way you describe would have a huge negative impact on my admin workflow.
 
Old 12-03-2017, 07:42 AM   #47
Launfal
Member
 
Registered: Jun 2014
Location: Ohio, USA
Posts: 65

Rep: Reputation: 49
Quote:
Originally Posted by GazL View Post
But they are intended to make it easier to install subsets: it's just not a complete solution.
To be fair, I understand the original intention was to modularize the _distribution_, not the installation. The present incarnation of the package sets seem to have been dictated more by the space available to the medium back in the day than by any desire to allow selective installation.

Quote:
E,F,KDE,XFCE, and a few other minor ones can all be left off if someone doesn't want those subsets. What they're not is a completely self contained selection point and things like the L set are a little more complicated.
And there's the rub. It's possible to use package sets the way you (and I) do, but the fact that they're not self-contained leads me to the inevitable conclusion that they were not originally designed for that.

Quote:
Yes, there's some KDE specific stuff in the L set that I don't really require, but I don't need to remove it all to get benefit from only syncing a subset. I save a lot of bandwidth and disk space -- though disk space is not all that relevant these days -- doing this.
L was the subset I specifically had in mind. A possible solution might be to move the libraries in L to the package sets that actually require them, so that leaving out a set would be closer to a modular install.

Quote:
No longer having sets at all in the way you describe would have a huge negative impact on my admin workflow.
I get that, and I'm not really advocating their removal. I'm just making the case that the recurring threads such as this one arise from a "misuse" of package sets to achieve a result not strictly in line with the maintainers' intent, and the resistance that these threads almost universally meet stems from the maintainers staying true to the vision.

For example, look at Alien's rsync patches script. There's no check for installed packages, because the assumption is a full install. SBO assumes a full install. Any support questions will inevitably arrive at "did you do a full install?" Now, slackpkg checks installed packages prior to updates, but I'm not really sure why, tbh, since it seems to be almost supporting partial installs. Another minor inconsistency that adds fuel to the controversy.

Prime computation based on available evidence: Full installation is the intended implementation of the designer's vision, and anything else will be left _solely_ to the admin.

I'm just saying that the presence of the sets themselves leads to an ambiguous understanding of why they exist, and to be "philosophically" consistent, they should probably be removed entirely and any modularization should be through tagfiles.

I'm not a maintainer, so obviously my interpretation of the intent and vision behind Slack is worthless in the grand scheme of things, but everything points to any request of the maintainers to more directly support modularization will be met with "be my guest."
 
3 members found this post helpful.
Old 12-03-2017, 08:40 AM   #48
orbea
Member
 
Registered: Feb 2015
Distribution: Slackware64-current
Posts: 795

Rep: Reputation: Disabled
If it works perfectly, someone will reinvent it...
 
2 members found this post helpful.
Old 12-03-2017, 08:40 AM   #49
LuckyCyborg
Member
 
Registered: Mar 2010
Posts: 274

Rep: Reputation: 72
Quote:
Originally Posted by Launfal View Post
To be fair, I understand the original intention was to modularize the _distribution_, not the installation. The present incarnation of the package sets seem to have been dictated more by the space available to the medium back in the day than by any desire to allow selective installation.
Excuse my ignorance, but in this day and age, looks like everyone put accent on modularization.

We talked about KDE and Qt. Look what happened to them, they exploded in a myriad of stand-alone sub-packages.

Could be that the Slackware implementation meanwhile became obsolete and it should be updated?

Quote:
Originally Posted by Launfal View Post
And there's the rub. It's possible to use package sets the way you (and I) do, but the fact that they're not self-contained leads me to the inevitable conclusion that they were not originally designed for that.
You noticed that everyone evangelize the full install, but in practice they use partial installations?

Quote:
Originally Posted by Launfal View Post
L was the subset I specifically had in mind. A possible solution might be to move the libraries in L to the package sets that actually require them, so that leaving out a set would be closer to a modular install.
I am an ignorant, but I seen there proposals and arguments on splitting the L set packages depending on their purpose, mainly console and graphics.

Quote:
Originally Posted by Launfal View Post
I get that, and I'm not really advocating their removal. I'm just making the case that the recurring threads such as this one arise from a "misuse" of package sets to achieve a result not strictly in line with the maintainers' intent, and the resistance that these threads almost universally meet stems from the maintainers staying true to the vision.

For example, look at Alien's rsync patches script. There's no check for installed packages, because the assumption is a full install. SBO assumes a full install. Any support questions will inevitably arrive at "did you do a full install?" Now, slackpkg checks installed packages prior to updates, but I'm not really sure why, tbh, since it seems to be almost supporting partial installs. Another minor inconsistency that adds fuel to the controversy.

Prime computation based on available evidence: Full installation is the intended implementation of the designer's vision, and anything else will be left _solely_ to the admin.

I'm just saying that the presence of the sets themselves leads to an ambiguous understanding of why they exist, and to be "philosophically" consistent, they should probably be removed entirely and any modularization should be through tagfiles.

I'm not a maintainer, so obviously my interpretation of the intent and vision behind Slack is worthless in the grand scheme of things, but everything points to any request of the maintainers to more directly support modularization will be met with "be my guest."
I do not think that the main issue is that the intended implementation is the full installation, and anything else left _solely_ to the admin, but he's left also with _no information_ about how to manage that.

And that happens in the day and age of a myriad of PPAs.
 
Old 12-03-2017, 09:03 AM   #50
Alien Bob
Slackware Contributor
 
Registered: Sep 2005
Location: Eindhoven, The Netherlands
Distribution: Slackware
Posts: 6,725

Rep: Reputation: 4092Reputation: 4092Reputation: 4092Reputation: 4092Reputation: 4092Reputation: 4092Reputation: 4092Reputation: 4092Reputation: 4092Reputation: 4092Reputation: 4092
Quote:
Originally Posted by LuckyCyborg View Post
Excuse my ignorance
Ignorance can never be excused.

Quote:
, but in this day and age, looks like everyone put accent on modularization.
We talked about KDE and Qt. Look what happened to them, they exploded in a myriad of stand-alone sub-packages.
Could be that the Slackware implementation meanwhile became obsolete and it should be updated?
Slackware is not "everyone". Pity for you.
Slackware will remain without automatic dependency resolution which is a requirement for "modularization" as you call it. Despite Darth Vader's comments that dependency resolution is not relevant, it is. Define a "package group" as you want, and who is going to determine that you have not missed a package? Are you going to run ldd and readelf against every binary and library in your package group? Didn't think so.

If you think it is time to move on, why are you still here.

IF you are not comfortable with managing your Slackware system, do a full install as recommended. It is not killing your computer to have libraries you think you will not need. But Slackware is not sitting in your chair therefore it will not make assumptions about what you want to do with the system. You get the swiss army knife, do not whine about the amount of utensils it contains.

Like I stated in my first reply, find a couple of like-minded Slackware users, and sit together to write down a set of tagfiles, then setup a public repository and share them with the rest of this community. That is the Slackware way to solve your issue. Whining is not.
 
8 members found this post helpful.
Old 12-03-2017, 09:04 AM   #51
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
Again, I think that the Package Series/Sets are not supposed to resolve dependencies, even in a rudimentary way.

I look at them as a way to categorize the packages, and that is not the same thing with dependency resolution.

Instead, it is more likely a description of their purpose. A label, not a dependency.

Also I believe that with a well made categorization, would be possible to partially modularize the Slackware.

At least, until to be possible to install it without KDE, X or whatever.

Last edited by Darth Vader; 12-03-2017 at 09:08 AM.
 
Old 12-03-2017, 09:15 AM   #52
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 LuckyCyborg View Post
Excuse my ignorance, but in this day and age, looks like everyone put accent on modularization.

We talked about KDE and Qt. Look what happened to them, they exploded in a myriad of stand-alone sub-packages.

Could be that the Slackware implementation meanwhile became obsolete and it should be updated?
While I am generally in favor of modularization you have to realize that Slackware was not designed that way from the inception. Reading Patrick's answers in this thread should have already made clear that Slackware won't change significantly in that respect. So, if you want a modularized Slackware you will have to fork it, there is no other way.

Quote:
You noticed that everyone evangelize the full install, but in practice they use partial installations?
I don't.

Quote:
I am an ignorant, but I seen there proposals and arguments on splitting the L set packages depending on their purpose, mainly console and graphics.

I do not think that the main issue is that the intended implementation is the full installation, and anything else left _solely_ to the admin, but he's left also with _no information_ about how to manage that.
It has been already stated that a dependencies list of each package won't be provided by Slackware (but you are free to build your own and there are several third party tools that, although not perfect, can help you doing that). Beyond that, I really don't know what kind of information could help the admin.

Quote:
And that happens in the day and age of a myriad of PPAs.
If you want PPAs, I guess you will need Ubuntu or such. Maybe Slackware is just not for you ?

Last edited by Didier Spaier; 12-03-2017 at 09:18 AM.
 
2 members found this post helpful.
Old 12-03-2017, 09:37 AM   #53
Launfal
Member
 
Registered: Jun 2014
Location: Ohio, USA
Posts: 65

Rep: Reputation: 49
Quote:
Originally Posted by LuckyCyborg View Post
Excuse my ignorance, but in this day and age, looks like everyone put accent on modularization.
We talked about KDE and Qt. Look what happened to them, they exploded in a myriad of stand-alone sub-packages.
Could be that the Slackware implementation meanwhile became obsolete and it should be updated?
That is an absolutely valid question, but given the only criterion that seems to be in play, the vision of the designer, the answer would appear to be "feel free, but not by us".

Quote:
You noticed that everyone evangelize the full install, but in practice they use partial installations?
I have, and the dichotomy is indeed interesting. I would replace "evangelize" with "be willing to support", but the observation seems to withstand scrutiny.

Quote:
I am an ignorant, but I seen there proposals and arguments on splitting the L set packages depending on their purpose, mainly console and graphics.
There were proposals, and they were unceremoniously dismissed. It was re-reading Pat's response to it that in large part led me to the opinion I currently hold.

Quote:
I do not think that the main issue is that the intended implementation is the full installation, and anything else left _solely_ to the admin, but he's left also with _no information_ about how to manage that.
No information, no support, and no interest in providing support, yup. Full install, or we're on our own. Salix or another derivative sometimes crops up as a viable suggestion regarding the issue.

To be clear, I'm not saying one side is more correct than the other. As users/admins, we're free to do whatever we want with the distro we're provided. I'm just making the point that Slack is designed a certain way, and it's looking pretty apparent that any attempts to work around that design will have to come from the community.
 
1 members found this post helpful.
Old 12-03-2017, 11:22 AM   #54
Drakeo
Senior Member
 
Registered: Jan 2008
Location: Urbana IL
Distribution: Slackware, Slacko,
Posts: 3,240
Blog Entries: 3

Rep: Reputation: 348Reputation: 348Reputation: 348Reputation: 348
For any of us that have built source Deb's and source Rpm's know there is no magic nothing automated. It is a lot of work writing the script.

as Eric said we have tags. Write your tag out and use it. I am sure slackpkg or the installer can handle the groups "designated group folder name" tag .

Puppylinux checks dependencies by using the "ldd" command then offers a direction to what library to install.
Write a tool using "ldd" to install from your tags do it.
 
Old 12-03-2017, 11:31 AM   #55
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
Brilliant, Drakeo!

You solved how to find missing dependencies for installing something. Then how you will do to NOT install something, like a particular DE, and all its dependencies?

Not because you are bad guy, but because those dependencies will conflict with the ones which you must use?

I.e. to continue to use the KDE4 while everyone else is happy that Slackware merged the Plasma5, just because your job needs that KDE4, nothing personal thought...

PS. No one ask you how to build the updated KDE4, but how to NOT install the Plasma5 at all.

Last edited by Darth Vader; 12-03-2017 at 11:46 AM.
 
Old 12-03-2017, 11:47 AM   #56
Drakeo
Senior Member
 
Registered: Jan 2008
Location: Urbana IL
Distribution: Slackware, Slacko,
Posts: 3,240
Blog Entries: 3

Rep: Reputation: 348Reputation: 348Reputation: 348Reputation: 348
Darth Vader you know and I know slackware is a source based system. So it is up to you to build and link libraries as needed. Many times in media stuff I had to recompile static so not to break third party stuff. Any one can build slackware.
Pat has chosen to put his puzzle together a certain way. We all can do that. The real issue is dynamic linked libraries.

How to bake a pie and how to slice it. mmm hungry
 
Old 12-03-2017, 11:50 AM   #57
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 Drakeo View Post
Darth Vader you know and I know slackware is a source based system. So it is up to you to build and link libraries as needed. Many times in media stuff I had to recompile static so not to break third party stuff. Any one can build slackware.
Pat has chosen to put his puzzle together a certain way. We all can do that. The real issue is dynamic linked libraries.

How to bake a pie and how to slice it. mmm hungry
Thanks you, I have no problems to build what I need.

BUT, again. How to do to NOT install what I DO NOT NEED?
 
Old 12-03-2017, 12:02 PM   #58
Drakeo
Senior Member
 
Registered: Jan 2008
Location: Urbana IL
Distribution: Slackware, Slacko,
Posts: 3,240
Blog Entries: 3

Rep: Reputation: 348Reputation: 348Reputation: 348Reputation: 348
Quote:
Originally Posted by Darth Vader View Post
Thanks you, I have no problems to build what I need.

BUT, again. How to do to NOT install what I DO NOT NEED?
To begin with if
Code:
ldd output | grep tags.
exclude tags that use them.
write the script you can do it you wrote the tags in order of your build.
build the tool you built the tags in order of your baked pie.

I look at it as a pie "blob" the tags are the recipe. pkgtool puts tags in tags out.
write the tool to
Code:
ldd | grep --exclude .
just a thought.
 
Old 12-03-2017, 12:09 PM   #59
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 Darth Vader View Post
BUT, again. How to do to NOT install what I DO NOT NEED?
When Slackware 15.0 will be released, read CHANGES_AND_HINTS.TXT. Then:
  • Figure out which added packages you probably won't need and/or could conflict with KDE4 and its deps. Just reading their description in /var/log/packages will give you a clue. Remove them.
  • Figure out which removed packages you would need. Rebuild them from the sources in 14.2. This of course includes KDE4 and deps.
  • If something is broken, find out which or the removed packages is missing, and reinstall it.
  • Publish you results to help other people who don't want to upgrade to KDE5.

Last edited by Didier Spaier; 12-03-2017 at 12:11 PM.
 
Old 12-03-2017, 12:10 PM   #60
LuckyCyborg
Member
 
Registered: Mar 2010
Posts: 274

Rep: Reputation: 72
Quote:
Originally Posted by Darth Vader View Post
BUT, again. How to do to NOT install what I DO NOT NEED?
If anything, I think "you will do not need" in the future the packages which right now are there:

http://bear.alienbase.nl/mirrors/ali...rent/5/x86_64/

Look with big attention to those packages. They are your own enemy. Note their names while waiting their apparition in -current. Then apply them the Sicilian Welcoming.

Last edited by LuckyCyborg; 12-03-2017 at 12:13 PM.
 
1 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:23 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