A way of extending the PKGTOOLS for handling Groups
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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:
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.
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."
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
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
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
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.
, 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.
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 08:18 AM.
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.
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.
You solved how to find missing dependencies for installing something. Then how you will do to NOTinstall 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 10:46 AM.
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.
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?
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
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 11:11 AM.
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 11:13 AM.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.