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.
But this is my issue, to know the _installed_ packages of the group, the response to "what should I install to get a working LAMP" should be given me by installer.
I don't think Slackware is for you. I am not trying to be funny or elitist. I genuinely mean this.
The info you get is not reliable. If the new package1 version now requires package2 to just run, you don't have to rebuild package2, so the information it will still share when you'll upgrade package1 will be outdated (it has now to be referenced in the same group as package1). This otherwise would require to upgrade the packages just to update their group info, which is IMHO insane (but still, it wouldn't have any sense to duplicate this information in the package logs, so you don't need to hack installpkg).
If you talk about a group creator who try to make a self-contained packages group, you are right.
But how many groups (or sets) are self-contained or need to be? Even in Slackware, right now we have only one: A, if I remember right.
Why I think that storing this information in the installed system is a good idea, at least for personal use?
For example, for my own use (I do not try to push it somewhere), I work to a small local site which shows me my own installed custom packages, categorized according their groups.
For me and my personal use, it has an utility.
Imagine a series of articles, in a news site, using either categories for organizing the articles, either putting a long list as index. I think is a difference on easiness to browse them. At least for me.
Last edited by Darth Vader; 12-06-2017 at 06:02 AM.
I don't think Slackware is for you. I am not trying to be funny or elitist. I genuinely mean this.
I hope you do not missed that here is now a theoretical discussion, a fun debate about a random subject, with interest for some. So, please take this way my words.
I ask for apologies, if you considered elsewhere.
I think is funny that in the last 25 years everyone was satisfied with the package sets, no one asked them to resolve dependencies, but now, when a little improvement of them was shown by someone, all orbit around dependencies. When even a simple mind like me understand that all is about one set, two sets, many sets.
Still, an enlightened mind could explain me the sense to store in package logs the "PACKAGE LOCATION", just comparative, after all I read in this thread.
I swear I see there the set from where the package was installed. It is not wrong to have it? According with @NonNonBa and others, it is wrong to store the sets name there, so I am confused.
To note that I do not question the Slackware design, instead I question some of the arguments from this thread.
Last edited by LuckyCyborg; 12-06-2017 at 08:03 AM.
Still, an enlightened mind could explain me the sense to store in package logs the "PACKAGE LOCATION", just comparative, after all I read in this thread.
It indicates where the package was located when you installed it. It can be ".../slackware/ap/...-1.txz" as well as "/mnt/nfs/bob/...-1.txz", as well as "/tmp/tmp.TS9ubk/...-1.txz". It may help you to retrieve the package file but don't tell more than the sets (which, again, are not meaningful) about its purpose.
Quote:
Originally Posted by Darth Vader
If you talk about a group creator who try to make a self-contained packages group, you are right.
No, it's just about tagging packages. If LAMP won't work without pkg1, pkg1 must be tagged "lamp" whatever other tags it has, but a package doesn't need to be rebuilt to become such a dependency, that the point.
So the/a right way would be to have all the tags in ONE file apart, locally updated each time you have to search something. One wget and two grep should be enough to get a decent parser for this DB, then you can concentrate on the heavy work: feed it so many people find it useful. This model leaves your hands free, you don't have to convince anyone to do anything to prove it valuable.
No, it's just about tagging packages. If LAMP won't work without pkg1, pkg1 must be tagged "lamp" whatever other tags it has, but a package doesn't need to be rebuilt to become such a dependency, that the point.
So the/a right way would be to have all the tags in ONE file apart, locally updated each time you have to search something. One wget and two grep should be enough to get a decent parser for this DB, then you can concentrate on the heavy work: feed it so many people find it useful. This model leaves your hands free, you don't have to convince anyone to do anything to prove it valuable.
Again, you assume and talk about what I call "self-contained" group, like you say: the LAMP and all its components, libraries and dependencies. And again, you are right.
BUT, like I said no one time, there is no rule that a group (or set) should be self contained. Of course, not. Demonstrated even by Slackware, with its one self-contained set from 14.
You can invent "Mozilla Apps" which contains Firefox, Seamonkey and Thunderbird, but I hope we agree that this group does not contains everything is needed for running those applications.
----------------------------
Now, I will tell you some things what I do practically with those groups.
Who said that a package should and must contains a program or library?
A package could contain also a site. For example a Moodle site, which is an powerful e-Learning Platform.
And Moodle use plugins, which can be installed in the form of another packages. And so I do.
Then, I tag the packages which contains Moodle plugins, imaginatively named, guess how? as "Moodle Plugins".
Honestly? I am glad that I do this, because those academic guys love to invent obscure names for their extensions.
And in the day when you should repair a monster sized site, like a Moodle with all its content, courses, students, and so on, where they messed with everything, you will agree with me.
----------------------------
At the end of day, it is just a generic way to categorize packages, or how you say "tagging" them.
And that categorization is of course, as the packages builder needs, not necessarily to resolve a precise self-contained objective, connected with a public or private repository, or not.
Like I said in another post, may be laughable or not, but for my own use this thing is very useful.
Last edited by Darth Vader; 12-06-2017 at 10:14 AM.
Again, you assume and talk about what I call "self-contained" group, like you say: the LAMP and all its components, libraries and dependencies. And again, you are right.
Not necessary. Assume in your DB you have the tags "minimal" or "recommended". If the new dependency bears it, then you won't add "lamp" because you can assume the user is informed it will probably get in trouble not having it. Now, if this package is so far only used by another server, it will obviously have to be tagged "lamp" because only the users of this server will have it installed while all the others will get their LAMP broken. You can't know once for all what information is useful about a particular package, so you need a way to update this on the fly.
"XFCE compilation made by Eric Hameleers" You can just ( cd /var/log/packages && ls -1 > $HOME/XFC_ERIC_PKGS.txt )
and there you have a complete list of packages -which is then easy to feed to installpkg &Co.
The idea of using links to package-names or db files is just as easily used without having to alter anything at all in pkgtools. Again, all the work is in compiling those lists of packages by-purpose, by-deps by-whatever-category. The lists will be useful or not -whether for just one person or many.
I recently praised a member who posted on one of the many minimal-install threads -I praised him because his list was truly concise and was clearly the product of real insight into what is needed and what is not to 'bootstrap' an installation under the most basic conditions. It was refreshing to see a real answer to that age-old quest for a tiny installation. Probably took the fellow a long time to learn that.
There's two ways to achieve an installation of just what you need and no more. The first and what most people do is to start thinning a full or nearly full installation. The second is to start with nothing or next to nothing, and add stuff to you get it all working. Either method is excruciating and costly -not only time, but nerves and maybe hardware! I'm pretty sure I drove an old drive or two over the brink by so many reboots and re-writes. It is well-proven that you can fry a complete system while trying re-compile slackware from scratch. Before trying that, finish the project of finding out just what is needed to boot to login on local hardware with no network or other exotic boot-time options.
Finding out how all that works and what is *not* needed, will help you then understand how one could re-compile a complete system -notice that I did not say re-compile a complete slackware system. Then, after all, since you are only one person, you'll understand why just one person would be crazy to do that very often.
Being 'The Slacker' is not the same as being 'a Slacker' -one mans' work saved is another mans learning experience. Slackware provides a rugged out-of-doors learning experience for the student who is ready. The KISS principle looks very different depending on whether you view it from the creator's side or the user's side. For the one it looks great: KISS and for the other it looks like this: SSIK -you do get to choose which side you are on, though. Thanks Pat, for all the things you didn't, don't and wont do! Yes, I *am* having fun, thank you.
Here's what I'm hearing from LuckyCyborg in this thread:
Quote:
I'm on a system with really limited disk space. I mean, really limited. I could take obvious steps like not installing KDE or Tex Live, but that's demonstrably not good enough. The installation is still taking up too much space. I really need to determine exactly which files I need to run the programs I need, and remove everything other than those.
If those were my needs, then I would absolutely not be using Slackware. I'd be using a distro optimized for a small installation footprint. Like Tinycore, maybe.
"XFCE compilation made by Eric Hameleers" You can just ( cd /var/log/packages && ls -1 > $HOME/XFC_ERIC_PKGS.txt )
and there you have a complete list of packages -which is then easy to feed to installpkg &Co.
The idea of using links to package-names or db files is just as easily used without having to alter anything at all in pkgtools. Again, all the work is in compiling those lists of packages by-purpose, by-deps by-whatever-category. The lists will be useful or not -whether for just one person or many.
I recently praised a member who posted on one of the many minimal-install threads -I praised him because his list was truly concise and was clearly the product of real insight into what is needed and what is not to 'bootstrap' an installation under the most basic conditions. It was refreshing to see a real answer to that age-old quest for a tiny installation. Probably took the fellow a long time to learn that.
There's two ways to achieve an installation of just what you need and no more. The first and what most people do is to start thinning a full or nearly full installation. The second is to start with nothing or next to nothing, and add stuff to you get it all working. Either method is excruciating and costly -not only time, but nerves and maybe hardware! I'm pretty sure I drove an old drive or two over the brink by so many reboots and re-writes. It is well-proven that you can fry a complete system while trying re-compile slackware from scratch. Before trying that, finish the project of finding out just what is needed to boot to login on local hardware with no network or other exotic boot-time options.
Finding out how all that works and what is *not* needed, will help you then understand how one could re-compile a complete system -notice that I did not say re-compile a complete slackware system. Then, after all, since you are only one person, you'll understand why just one person would be crazy to do that very often.
Being 'The Slacker' is not the same as being 'a Slacker' -one mans' work saved is another mans learning experience. Slackware provides a rugged out-of-doors learning experience for the student who is ready. The KISS principle looks very different depending on whether you view it from the creator's side or the user's side. For the one it looks great: KISS and for the other it looks like this: SSIK -you do get to choose which side you are on, though. Thanks Pat, for all the things you didn't, don't and wont do! Yes, I *am* having fun, thank you.
This is a beautiful post. I thought you guys were all the same, I guess I was wrong. There is nothing wrong with being/wanting something different. If people helped each other more, it would be more easy to accomplish. What can I do? Grab a couple packages, find all dependencies and give Darth a list. Might be a small contribution but at least its something. Get a few hundred people to contribute a couple of packages and there depends. Shouldn't no one man have to do 1200 packages himself unless he wants to. Because some of you don't share his vision, doesn't mean you shouldn't contribute. To each his own.
Last edited by PROBLEMCHYLD; 12-06-2017 at 01:54 PM.
building tools to be used once and put in a drawer has been the Slackware way for years. I have my tools on the github and the bitbucket.
I do all this for me and my Slack. You may find your slack here also.
We was sober in college.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.