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 12-03-2017, 12:13 PM   #61
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 Didier Spaier View Post
When Slackware 15.0 will be released, read CHANGES_AND_HINTS.TXT. Then:
15.0 your teasing me now. getting hungry for a good pie.
 
Old 12-03-2017, 12:22 PM   #62
LuckyCyborg
Member
 
Registered: Mar 2010
Posts: 274

Rep: Reputation: 72
The KDE is a pie with too much fat, according with my computer. Never able to run it, even it is somewhere here.

And I understand that KDE5 is even fatter.
 
Old 12-03-2017, 12:22 PM   #63
bassmadrigal
Senior Member
 
Registered: Nov 2003
Location: Newport News, VA
Distribution: Slackware
Posts: 4,544

Rep: Reputation: 2494Reputation: 2494Reputation: 2494Reputation: 2494Reputation: 2494Reputation: 2494Reputation: 2494Reputation: 2494Reputation: 2494Reputation: 2494Reputation: 2494
Quote:
Originally Posted by Darth Vader View Post
BUT, again. How to do to NOT install what I DO NOT NEED?
Simple (according to you)... find out what dependencies in l/ are for KDE and are not needed and then take your tagfile for l/ and remove those packages from it.

===========================================

Your big intent in doing this is so you don't have to install KDE and it's associated dependencies, and you mention it has other implications allowing people to just have a LAMP server or something else, but where do you draw the line in what should be included in the installer? Should we support a non-development install (leave out d/ and assume they'll only be installing pre-compiled binary packages)? What about a multimedia install, leaving out all the server related things? Should it offer just a games install, and leave out all server, productivity, and development programs? What about an email server? mysql (well, mariadb) server? C++ developer? Web browsing?

You can have thousands of different categorizations and how should Pat decide what should be included and what should be discarded? And how is this easily done without dependency resolution? If you really think it is possible, you're lying to yourself. In reality, for KDE5, it might be easier to make a list of what it relies on that are probably independent of everything else in the system, but to go beyond that with other categories is just not easily doable without a list of dependencies.

You're pushing this for easy removal of KDE5, and if that list of packages is readily available, it might make this a bit easier, but that "list" might only be a partial list of what KDE5 needs over KDE4 and not an all-inclusive list. To get a proper list, you can't do it without a list of dependencies that you can cross reference for each package. Who's to say that a particular lib, while primarily used by KDE, isn't used by a different program? Is qt4/qt5 only used for KDE packages (someone else mentioned wpa_gui from wpa_supplicant uses qt)? So, if you remove qt4/qt5, are other non-KDE programs going to be broken?

Quit lying to yourself (and us) saying this is simple and can be done without a proper list of dependencies...
 
2 members found this post helpful.
Old 12-03-2017, 12:29 PM   #64
gmgf
Senior Member
 
Registered: Jun 2012
Location: Bergerac, France
Distribution: Slackware
Posts: 1,135

Rep: Reputation: 391Reputation: 391Reputation: 391Reputation: 391
It's just an obsessional delirium
 
1 members found this post helpful.
Old 12-03-2017, 12:40 PM   #65
LuckyCyborg
Member
 
Registered: Mar 2010
Posts: 274

Rep: Reputation: 72
TBH, no guy consider funny the perspective to hard work several months if not more, in the near future, just to going back to actual state of facts.

I do not cry worried of the wellness of the OP, he's more than capable to run alone a distribution, if he has time for this, like he claimed.

Obsessions? No.

Using wrong tools? Yes.

And the maintainers are so friendly on helping him even a bit, even with a insignificant chunk of information.

You really think that Eric Hameleers does not understand the OP issue, while he's the most qualified person here to offer information about KDE5 structure and how to remove it?

Still I believe that the OP idea of groups is amazing, even it will not be adopted, more likely.

Last edited by LuckyCyborg; 12-03-2017 at 12:44 PM.
 
Old 12-03-2017, 01:45 PM   #66
gmgf
Senior Member
 
Registered: Jun 2012
Location: Bergerac, France
Distribution: Slackware
Posts: 1,135

Rep: Reputation: 391Reputation: 391Reputation: 391Reputation: 391
You believe and think what you want, me too
 
Old 12-03-2017, 02:04 PM   #67
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 bassmadrigal View Post
Your big intent in doing this is so you don't have to install KDE and it's associated dependencies,
What's wrong with having an interest?

Quote:
Originally Posted by bassmadrigal View Post
and you mention it has other implications allowing people to just have a LAMP server or something else,
Sure thing, could be extended in many ways.

Quote:
Originally Posted by bassmadrigal View Post
but where do you draw the line in what should be included in the installer?
About WHAT installer you talk, man? Who said something about the installer? Me? NO!

My proposal is only about the ability to add a specific file in every Slackware package, process it by installpkg and adding a particular line in package entry from database. That's all!

I do not said or suggested what categories or groups to be added in that line, nothing!

I talked just about this features, which is probably about several lines to add in installpkg and tons of hard work from maintainers, even I can provide a suggestion how to do an initial population of those files.

Quote:
Originally Posted by bassmadrigal View Post
Should we support a non-development install (leave out d/ and assume they'll only be installing pre-compiled binary packages)? What about a multimedia install, leaving out all the server related things? Should it offer just a games install, and leave out all server, productivity, and development programs? What about an email server? mysql (well, mariadb) server? C++ developer? Web browsing?
WHY you ask me?, after all I am not the one who can decide which groups will add the Slackware maintainers, at the end of day.

My mere interest is they to show me which packages will/are added for Plasma5, in the rest I am not so worried if they invent hundred groups or only two.

Quote:
Originally Posted by bassmadrigal View Post
You can have thousands of different categorizations and how should Pat decide what should be included and what should be discarded? And how is this easily done without dependency resolution? If you really think it is possible, you're lying to yourself. In reality, for KDE5, it might be easier to make a list of what it relies on that are probably independent of everything else in the system, but to go beyond that with other categories is just not easily doable without a list of dependencies.
The first one which I imagine to be prepared on that categorization could/would be KDE5, because it will be the next fresh whole whale to be added to tree.

Well, I accept that I would have some profit from this unexpected event.

Quote:
Originally Posted by bassmadrigal View Post
You're pushing this for easy removal of KDE5, and if that list of packages is readily available, it might make this a bit easier, but that "list" might only be a partial list of what KDE5 needs over KDE4 and not an all-inclusive list.
Yes, knowing that a particular package was added for the KDE5 usage, will give me the ability to consider its usefulness.

MANUALLY, to not be worried about additional tools.

Quote:
Originally Posted by bassmadrigal View Post
To get a proper list, you can't do it without a list of dependencies that you can cross reference for each package. Who's to say that a particular lib, while primarily used by KDE, isn't used by a different program? Is qt4/qt5 only used for KDE packages (someone else mentioned wpa_gui from wpa_supplicant uses qt)? So, if you remove qt4/qt5, are other non-KDE programs going to be broken?
Again you ask me about problems which I am unable to resolve. I offer only the way, not also the solution, and I cannot ever offer it, as I am no Slackware developer.

Quote:
Originally Posted by bassmadrigal View Post
Quit lying to yourself (and us) saying this is simple and can be done without a proper list of dependencies...
If you are kind to think five seconds, instead to write shiny words, because you are an intelligent man, I am pretty sure you will figure out that that categorization is exactly the reverse of the dependencies resolution and much more generic. Also, much more easy to process via an BASH script.


Instead of telling on every package its dependencies, you have just to say its category, its purpose or call how you want. BUT, its all about where it belongs to.

At the end of day, IF that categorization fail somewhere, blame the one who will make it, not me.

Last edited by Darth Vader; 12-03-2017 at 02:54 PM.
 
Old 12-03-2017, 02:59 PM   #68
LuckyCyborg
Member
 
Registered: Mar 2010
Posts: 274

Rep: Reputation: 72
@bassmadrigal

Just to clarify, I am the one who suggested that those package groups could be used by the installer.
 
Old 12-03-2017, 03:01 PM   #69
bassmadrigal
Senior Member
 
Registered: Nov 2003
Location: Newport News, VA
Distribution: Slackware
Posts: 4,544

Rep: Reputation: 2494Reputation: 2494Reputation: 2494Reputation: 2494Reputation: 2494Reputation: 2494Reputation: 2494Reputation: 2494Reputation: 2494Reputation: 2494Reputation: 2494
Quote:
Originally Posted by Darth Vader View Post
About WHAT installer you talk, man? Who said something about the installer? Me? NO!

My proposal is only about the ability to add a specific file in every Slackware package, process it by installpkg and adding a particular line in package entry from database. That's all!
Sorry, I read pkgtools and mentally thought the installer since you were not wanting to install KDE5 stuff.

Quote:
Originally Posted by Darth Vader View Post
WHY you ask me?, after all I am not the one who can decide which groups will add the Slackware maintainers, at the end of day.

My mere interest is they to show me which packages will/are added for Plasma5, in the rest I am not so worried if they invent hundred groups or only two.
So, you want all this extra work so you can uninstall Plasma5, which could be easily done by creating a blacklist file with the required packages. If you wanted to branch this out beyond Plasma5, you could create a site with various blacklist files that could be added to slackpkg. Then you just add those packages in those blacklist files to yours and then run slackpkg clean-system.

Quote:
Originally Posted by Darth Vader View Post
If you are kind to think five seconds, instead to write shiny words, because you are an intelligent man, I am pretty sure you will figure out that that categorization is exactly the reverse of the dependencies resolution and much more generic. Also, much more easy to process via an BASH script.
But how do you create those lists, ensuring it won't break any installed programs, without knowing what the dependencies of those packages are? Plasma5 is a bit easier since it is fresh and hasn't been added yet, so there's an easy to find list of software that had to be added to ensure it will work. But there could be packages that were added for KDE3 support and were used in newer KDE versions, but they aren't in the minds of Pat and team that they're "KDE dependencies" even if nothing else relies on them. The only way to find out what packages are only used for KDE is to have the dependencies listed. Otherwise, it will be a partial list, and other lists become impossible (without manually checking dependencies using ldd or various tools out there).

Quote:
Originally Posted by Darth Vader View Post
Instead of telling on every package its dependencies, you have just to say its category, its purpose or call how you want. BUT, its all about where it belongs to.
But to get it added to the correct category and not have it possibly break other parts of the system, you need to know what packages rely on it... dependencies. There would need to be a lot of work to check that any categories specified that when removed, aren't going to break other pieces of software when removed. And those categories would probably need to have dependencies too, because what if someone wants to keep qt5, but remove KDE. So, you'd need to separate out qt5 from KDE, but if someone removes qt5, they'd need to remove kde. And now dependencies have been introduced into pkgtools...

Quote:
Originally Posted by Darth Vader View Post
At the end of day, IF that categorization fail somewhere, blame the one who made it, not me.
Or the blame could be on the person who suggested this on a distro that does not have an ability to check what dependencies are in the system
 
1 members found this post helpful.
Old 12-03-2017, 03:02 PM   #70
bassmadrigal
Senior Member
 
Registered: Nov 2003
Location: Newport News, VA
Distribution: Slackware
Posts: 4,544

Rep: Reputation: 2494Reputation: 2494Reputation: 2494Reputation: 2494Reputation: 2494Reputation: 2494Reputation: 2494Reputation: 2494Reputation: 2494Reputation: 2494Reputation: 2494
Quote:
Originally Posted by LuckyCyborg View Post
@bassmadrigal

Just to clarify, I am the one who suggested that those package groups could be used by the installer.
Apologies... I started reading this last night and maybe I mixed up who stated it... or maybe I just read pkgtools and automatically thought of the installer. But thanks for the clarification
 
Old 12-03-2017, 03:41 PM   #71
heyjann
Member
 
Registered: Dec 2015
Posts: 72

Rep: Reputation: Disabled
Quote:
Originally Posted by Darth Vader View Post
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.
One of the reasons I asked about how you would classify libpng is indeed that it is needed for lots of stuff beyond kde, as others are also mentioning about qt etc in the context of whether dependency resolution comes into play or not. My file server perhaps won't suffer if I excise libpng as a punishment for also being a KDE dependency, but my print server already might: ghostscript (in ap) uses it too. Note that libraries that are really only useful to KDE users are actually mostly in the KDE series despite being libraries, awaiting a slackpkg remove kde command.

I'd say to anyone: just install libpng, it'll probably be useful. Most will agree there, but not necessarily when I'd say the same about phonon. Opinions will vary. PV seems to be saying we probably don't really need pam and you perhaps disagree. In Slackware, he has the final say for now, but Dlackware is there too, let's see if it takes off in a big way (I'm not rooting for or against it. I am happy that it exists but I have no interest in using it).

Quote:
Originally Posted by Launfal View Post
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.
[...]
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.
[...]
Any support questions will inevitably arrive at "did you do a full install?"
Many libraries and support programs will be required by multiple package sets, like libpng needed for stuff in x, xap, ap and e and probably more. Some development tools in d assume availability of stuff from n (network).
So moving stuff to 'sets that actually require them' means having the same package in multiple sets. Or there needs to be a separate series of "libraries you most probably need anyway", tagged "Libraries" if you want... but that is already what the l series is.

I think that the series back in the old days might have behaved more like you'd expect, but now a lot of Linux software is moving somewhat away from doing one thing well and will try to compile with support for x, y and z and whatever else it finds on the system, and the binary will then end up depending on the libraries.
And it's probably better to let it, otherwise people will complain "y is in slackware so why is b not built with y support?" while other people complain that c does not work without mentioning upfront that they did not install z because they thought it was probably not necessary.

There is a bit of an overlap between the people wanting to cut down their install to the barebones, and the people running into trouble, and the people not interested in first trying to reproduce their issue on a full install before asking for assistance.
So yes I am sure some experts here 'hypocritically' skipping e, f and kdei themselves while still not fully trusting first-timers to have excluded 'only some useless stuff'.

Now I would not personally mind if KDE and xfce4 would get the same treatment as MATE: different versions available only via 3rd party repositories.
But this would put a lot of burden back on alienbob and rworkman and others.
Firefox, fluxbox, texlive, emacs, thunderbird, gimp: if they all go to SBo and/or slackpkg+ compatible repos, I won't lose sleep. But if the Slackware base becomes too basic for some, I'm sure that this won't improve the reviews (OpenBSD get flak for it all the time, speaking of solid base systems to build on).
 
Old 12-03-2017, 06:26 PM   #72
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 bassmadrigal View Post
Sorry, I read pkgtools and mentally thought the installer since you were not wanting to install KDE5 stuff.



So, you want all this extra work so you can uninstall Plasma5, which could be easily done by creating a blacklist file with the required packages. If you wanted to branch this out beyond Plasma5, you could create a site with various blacklist files that could be added to slackpkg. Then you just add those packages in those blacklist files to yours and then run slackpkg clean-system.



But how do you create those lists, ensuring it won't break any installed programs, without knowing what the dependencies of those packages are? Plasma5 is a bit easier since it is fresh and hasn't been added yet, so there's an easy to find list of software that had to be added to ensure it will work. But there could be packages that were added for KDE3 support and were used in newer KDE versions, but they aren't in the minds of Pat and team that they're "KDE dependencies" even if nothing else relies on them. The only way to find out what packages are only used for KDE is to have the dependencies listed. Otherwise, it will be a partial list, and other lists become impossible (without manually checking dependencies using ldd or various tools out there).



But to get it added to the correct category and not have it possibly break other parts of the system, you need to know what packages rely on it... dependencies. There would need to be a lot of work to check that any categories specified that when removed, aren't going to break other pieces of software when removed. And those categories would probably need to have dependencies too, because what if someone wants to keep qt5, but remove KDE. So, you'd need to separate out qt5 from KDE, but if someone removes qt5, they'd need to remove kde. And now dependencies have been introduced into pkgtools...



Or the blame could be on the person who suggested this on a distro that does not have an ability to check what dependencies are in the system
Great words, but you do what you do, and you go back to resolving dependencies...

Why you insist on that package dependencies and their resolution? For what?

To understand about what I talk myself in this thread, let's do a thought experiment:

Imagine that in -current, you create two new folders, "kdelibs" and "lamp", where you do symlinks to the packages which corresponds to those two new "sets", and somehow the installpkg is modified to register both the original path and the symlinked path in database.

That's all!

You can visually inspect those new "sets" or to consider their names from the installed packages database. Again, that's all.

No magic included there, no dependency resolution, nothing. It is just a packages categorization made by maintainers, having same dependency resolution support like the today package sets: next to zero.

Same works also my proposed design, over that files, instead of using folders and symlinks.

BUT, this categorization permit to users to know which ones are the packages required by KDE or to build a LAMP stack.

I for one, I consider that we arrived to need a better categorization of the packages. IF my suggestions are accepted or not, that's another story.

IF I have a particular advantage if this design is adopted, this is yet another story.

Or is a shame to have an advantage, while you offer something to others?

Last edited by Darth Vader; 12-03-2017 at 06:55 PM.
 
Old 12-03-2017, 06:55 PM   #73
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
@Darth Vader

You can use hard links to do that. For instance this folder http://slackware.uk/slint/x86_64/sli...ng/slint/lxde/ includes only hardlinks.

This allows to type "slapt-get install-set lxde" and get them all (even without dependencies resolution, assuming that all other packages are installed).

But you could as well implement that with a set of tag files, or do I miss something?
 
Old 12-03-2017, 06:59 PM   #74
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 Didier Spaier View Post
@Darth Vader

You can use hard links to do that. For instance this folder http://slackware.uk/slint/x86_64/sli...ng/slint/lxde/ includes only hardlinks.

This allows to type "slapt-get install-set lxde" and get them all (even without dependencies resolution, assuming that all other packages are installed).

But you could as well implement that with a set of tag files, or do I miss something?
Basically, in that unique "install/slack-groups" file you can specify tons of groups/categories. No limit for their number.

You can do precisely the same with folders and symlinks or hardlinks, but at a huge number of virtual "sets", the "information stored in files" variant is more clean. Imagine that you have one hundred virtual "sets" ...

Also, when using "install/slack-groups", the information is preserved even when the package is inspected out of tree.

The tags could be used only for a particular "view" of packages, that's why my variant is more versatile, because gives you a simple way to present tons of "views".

Last edited by Darth Vader; 12-03-2017 at 07:05 PM.
 
Old 12-03-2017, 07:05 PM   #75
OldHolborn
Member
 
Registered: Jul 2012
Distribution: Slackware!
Posts: 136

Rep: Reputation: 103Reputation: 103
Quote:
Originally Posted by Darth Vader View Post
Great words, but you do what you do, and you go back to resolving dependencies...

Imagine that in -current, you create two new folders, "kdelibs" and "lamp", where you do symlinks to the packages which corresponds to those two new "sets", and somehow the installpkg is modified to register both the original path and the symlinked path in database.

That's all!
don't forget one for Multimedia, another for Productivity, another for Server, another for Education, another for Gaming, another for ...

And hope that your definition of a category isn't different from someone elses

Or are we to ask that Slackware ships with Multimedia_DarthVader, Multimedia_OldHolborn, Multimedia_SomeoneElse1, Multimedia_SomeoneElse2, Mu...

It all gets very silly very fast
 
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: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