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 you published not one, but 4 or 5 programs, plus that suite for Slackware configuration, were was a lot of gui programs plus an installer. I do not remember how was named.
Eric, I explained that my idea is not a dependency resolution, but just an extension of today sets from "single" to "multiple", using a file instead of folders.
You keep saying this and we keep telling you how it is wrong. How can you know whether or not a package, when removed, will not cause issues with other packages? By knowing what its dependencies are.
There's no other way to know that (short of blindly removing things and trying them out, but in a distro with over 1000 packages, that's pretty much impossible to ensure there's no conflicts).
Quote:
Originally Posted by Darth Vader
You hang in this forum since 2010, how you managed to not learn at an advanced level the Linux?
Just because someone joined this forum doesn't mean they've used Linux from that point on. They might've had a question, then found it was easier to go back to Windows, then decided with the way Microsoft is pushing Windows that they wanted to try Linux out again. Based on other forums I've frequented, I'd imagine a huge percentage of users have 10 posts or less. They have a question, get it answered (or sometimes don't get it answered) and then never come back. They may or may not still use Linux.
You keep saying this and we keep telling you how it is wrong. How can you know whether or not a package, when removed, will not cause issues with other packages? By knowing what its dependencies are.
There's no other way to know that (short of blindly removing things and trying them out, but in a distro with over 1000 packages, that's pretty much impossible to ensure there's no conflicts).
Lets put the things this way: could the actual package sets has dependencies or they manage dependencies? I don't think so.
Same that idea of groups, which is just a way to specify multiple virtual "sets". It is agnostic of dependencies management, just like the package sets.
Quote:
Originally Posted by bassmadrigal
Just because someone joined this forum doesn't mean they've used Linux from that point on. They might've had a question, then found it was easier to go back to Windows, then decided with the way Microsoft is pushing Windows that they wanted to try Linux out again. Based on other forums I've frequented, I'd imagine a huge percentage of users have 10 posts or less. They have a question, get it answered (or sometimes don't get it answered) and then never come back. They may or may not still use Linux.
I figured out that, and same kind of explanation given also @LuckyCyborg.
Last edited by Darth Vader; 12-04-2017 at 09:03 PM.
Their utility is mainly informational, just like I said, a categorization of the packages.
BTW, I am aware about their possible utility for installer, but this is an (collateral) effect of the design, as even the today package sets could be considered a form to categorize and organize the packages.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.